On 06/23/2011 05:04 PM, Somebody in the thread at some point said:

On 23 June 2011 08:51, Andy Greenandy.green@linaro.org wrote:

...

Hi -

I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again.

What does this mean for the 11.06 OMAP Android release? Will it use your 3.0 kernel or will it use 2.6.35 again?

I'm not certain what the android folks are doing but I have also tagged "android-2.6.38-2011-06" on my repo which is a 2.6.38 branch that boots into Android fine with 3D acceleration, just with 640 x 480 raster and framebuffer. I know Zach is familiar with this and has been preparing the way, so I think we might see that one go out this month.

...

I introduced two new branches yesterday:

http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=shortlog...

• omap4_defconfig

http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=shortlog...

• android_omap4_defconfig

that are linus' HEAD and common-3.0 (androidized nearly linus HEAD) based and have the API v4403 SGX stuff on them.

How hard is it to just grab the OMAP-specific patches from 3.0-rc<latest>and move them to 2.6.39?

Well, the point is linux-linaro-* would be a common place that all the LT kernels can contribute to.

For example if this new 4430 Alsa implementation has dependencies on Alsa core stuff only in 3.0, we're back in the same bind as the forwardport of the 2.6.38 Alsa driver which has "special needs" in Alsa core stuff that conflicts with other LEB audio driver assumptions.

In the end demand downstream of us is only for 3.0, they won't get any direct benefit from time spent servicing 2.6.39.

...

The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now.

Is this something that upstream is also aware of and tracking?

What the EHCI debug effort you mean? There's no fruit from it yet but sure, since we happen to be riding Linus HEAD if we find something applicable to upstream I don't doubt Jassi will send it there straight away.

-Andy

On 06/23/2011 07:44 PM, Somebody in the thread at some point said:

On Thu, 2011-06-23 at 09:04 -0700, Deepak Saxena wrote:

...

...

The status is currently on linus HEAD, Panda EHCI is broken which is a bit of a downer; Jassi is taking a look at it. Also video is coming up nicely with 1080p raster, but it is stuck at 640 x 480 framebuffer viewport inside that right now.

Is this something that upstream is also aware of and tracking?

There is an easy revert for the ehci issue: git show 7e6502d577106fb5b202bbaac64c5f1b065e6daa | patch -p1 -R

Awesome, I'll give it a go later.

Thanks for letting us know.

-Andy

On 06/23/2011 07:39 PM, Somebody in the thread at some point said:

...

I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again.

$ git diff --shortstat v2.6.39..linaro-2.6.39 sound/ 158 files changed, 20097 insertions(+), 6899 deletions(-)

$ git diff --shortstat linaro-2.6.39..v3.0-rc4 sound/ 65 files changed, 4586 insertions(+), 3612 deletions(-)

So please lets stop that "linaro-2.6.39 is just 2.6.39" rhetoric when numbers show that linaro-2.6.39 is much closer to the strictly speaking still nonexistent 3.0 than 2.6.39.

Well, I don't think it is rhetoric, I am not trying to make any point or suggest you should do anything different. I'm not sure what I can take from the gross diffstat number anyway, it could mean a few things from "holy crap they changed the APIs totally" to "oh they fixed a lot of spelling mistakes".

I was just noting - because sound didn't seem to come up on .39 - that the situation is the same if:

a) you have a chunk of something coming from behind like .35 as the .38 Panda onboard Alsa stuff was, and it carries with it deps on changes to core code that are likely to upset other SoC files on there, or

b) you have a chunk of something coming from ahead (and there is meant to be shiny new Alsa Panda support in HEAD) backporting and it too has deps on newer core stuff that if it was brought in, would also upset the other Soc files on there who are still coded against older core APIs.

Yes it can be straightened out but I ask myself is that what I should be doing instead of the stuff I am doing. I guess that is to the point of the philosophical questions you are asking later in this mail.

In fact tomorrow I will be on a call and the question will come, "is there a 11.10 Panda kernel tree for us to package yet?" and since they told they want a 3.0 result, "yes a 3.0 tracking branch is started and pretty workable already" is the right answer compared to one involving the number 39. I realize that's not really fair considering you kitted your tree out with so much stuff from the future but that is an accurate assessment I think.

I'm seriously starting to question the usefulness of the "Linaro" kernel tree in fact. For one year that I've been putting such a tree together, the feedback and response have been less than overwhelming. The idea was to _consolidate_ the work that the various groups within Linaro was producing into a single and coherent whole without screwing up the other groups' work, but so far this hasn't been a great success for various reasons.

Well this job is very tough.

What stopped more being usable from our stuff was DSS contamination risk on OMAP3, since the bits of DSS not already upstream have been a continuing challenge to us to even understand let alone fix; and trailing entrails from uplevelled chunks leaking into common core code.

In short once the goodies upstream run out (but to be fair TI has a huge amount of goodies upstream), our LT tree anyway has this foaming crud of uplevelled, known-deprecated and BSP-type patches from unknown upstream trees frozen in time. That is not the ideal raw material for what you're trying to do.

I expect it can be that we can do a bit better in the next months in terms of tighter integration with vendor "topic repo" sources directly, and get a somewhat more wholesome tree.

So I'm asking people for comments about this tree.

• Is this useful?

• Is it important?

• Are _you_ using it?

Well I am using it and intend to continue. Ubuntu are using it for Panda via that path too.

• Is solving the ARM fragmentation problem still a Linaro priority?

• Is the Linaro kernel effective for this?

Half a year ago when I did ask for comments about the usefulness of the linaro-next tree, I got almost no responses as I suspected, and I therefore dropped that tree to concentrate my efforts on the Linaro "stable" branches. If even the stable branch doesn't steer more interest than it does now then this effort is just wasted. Either our process is to blame, our priorities are wrong, or some efforts are diverted where they shouldn't.

No not at all, I reiterate there's no message you ought to do something different from me. In fact, I am hoping for linux-linaro-3.0 to appear and we go back to basing on that as before.

One reason for the Linaro tree was to help LTs moving ahead rather than sticking to ancient kernels. Now it seems that everyone wants to get ahead of the actual latest release from kernel.org which is a radical shift. Does this mean that vendors and co now are getting used to the upstream pace and they're going to move to a rebasing workflow for real, or they're just fooled by the marketing prospects of a meaningless major kernel version bump? If the former that would be wonderful and maybe the Linaro kernel outlived its usefulness. If the later... well... what can I say here?

Well I think you may be right with it being the latter this time, in which case we shouldn't read too much into it.

In any case that doesn't make a strong case for the "Linaro" kernel. We could as well just patch the latest Ubuntu kernel, the latest Android kernel, or whatever existing distro or vendor kernel, in order to showcase the Linaro initiated work and results. In practice that's what I see people doing right now anyway. Pushing that work into mainline is what matters the most in the end, and _that_ should always be Linaro's top priority.

I don't feel compelled to fight for the survival of the Linaro kernel either if it is not widely used and significantly useful. I'm more effective fighting with mainline kernel people: it is much more interesting and useful with lasting results.

I think a multi- LT branch integration into a single tree has a lot of value, it is just really tough to ever get even near 100% in terms of what you can take. But as happened earlier you were able to pull the whole tilt.39, admittedly it's cheating a bit because there was no sound meddling of SGX in there to mess it up. But you can read from that you are dependent on the quality of the contributor LT branches in how far you can succeed to integrate.

Unfortunately we're not always all that in control of the quality of that but I think it will generally get better on our side anyway.

-Andy

On 23 June 2011 11:39, Nicolas Pitre nicolas.pitre@linaro.org wrote:

On Thu, 23 Jun 2011, Andy Green wrote:

...

When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before.

The base will be just as good as the contributions made by people to it. And besides a few notable exceptions such as yours, I didn't get much from people in terms of patches and/or pull requests.

I'm seriously starting to question the usefulness of the "Linaro" kernel tree in fact.  For one year that I've been putting such a tree together, the feedback and response have been less than overwhelming.  The idea was to _consolidate_ the work that the various groups within Linaro was producing into a single and coherent whole without screwing up the other groups' work, but so far this hasn't been a great success for various reasons.

- Is solving the ARM fragmentation problem still a Linaro priority?

From my POV, this is definitely a yes.

- Is the Linaro kernel effective for this?

This I am not 100% sure about. I've seen quite a bit of activity on linux-arm-kernel after LDS with folks moving drivers out of arch/arm and I am beginning to see DT work being posted upstream. How much of that work is being send directly to you vs you having to stay on top of various changes in the community and pull those in proactively or as in the case of the ALSA issues, reactively? In other words, how much of your time is spent on keeping up with all the changes you need to pull into the Linaro kernel? This kernel is useful as place to test patches that are headed upstream in a single tree but unless all the LTs are using it as their base and are sending you patches on a regular basis, I do wonder if you're spending cycles on this tree that could be used on more core consolidation work.

Half a year ago when I did ask for comments about the usefulness of the linaro-next tree, I got almost no responses as I suspected, and I therefore dropped that tree to concentrate my efforts on the Linaro "stable" branches.  If even the stable branch doesn't steer more interest than it does now then this effort is just wasted. Either our process is to blame, our priorities are wrong, or some efforts are diverted where they shouldn't.

One reason for the Linaro tree was to help LTs moving ahead rather than sticking to ancient kernels.  Now it seems that everyone wants to get ahead of the actual latest release from kernel.org which is a radical shift.  Does this mean that vendors and co now are getting used to the upstream pace and they're going to move to a rebasing workflow for real, or they're just fooled by the marketing prospects of a meaningless major kernel version bump? If the former that would be wonderful and maybe the Linaro kernel outlived its usefulness.  If the later... well... what can I say here?

I don't know that we're hearing that all vendor trees want to be on the latest kernel. What I'm reading from Andy's perspective is that it is easier to just work directly against upstream changes that to try and figure out what all changes need to be picked into 2.6.39..

From ST-E's landing team perspective, by the time they start

on their work, it will be time for a 3.x tree.

In any case that doesn't make a strong case for the "Linaro" kernel. We could as well just patch the latest Ubuntu kernel, the latest Android kernel, or whatever existing distro or vendor kernel, in order to showcase the Linaro initiated work and results.  In practice that's what I see people doing right now anyway.

Pushing that work into mainline is what matters the most in the end, and _that_ should always be Linaro's top priority.

+1

I don't think it makes sense to have a Linaro-only tree for the sake of having a place to showcase Linaro's work. We don't want to be different from a kernel POV in my opinion. Our goal is to fix the kernel upstream, improve performance, consolidate architectures, help vendors cleanup their code. If we want to show case work, there are other ways to do it including just collating commit messages and providing high level summaries of work being done.

I don't feel compelled to fight for the survival of the Linaro kernel either if it is not widely used and significantly useful.  I'm more effective fighting with mainline kernel people: it is much more interesting and useful with lasting results.

My opinion is that if there are no patches coming in from within Linaro and all of the work you are doing is to simply integrate patches that are already upstream-bound, then we should just kill the Linaro tree and focus 100% on an upstream. Instead of having a "Linaro-branded" kernel, could we just have a branch in the arm-soc tree that is a consolidation branch and is widely used beyond just Linaro builds and that acts as a more public and upstream arm-next tree?

~Deepak