TI LT 3.0 Tracking branches
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. I introduced two new branches yesterday: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking-android - 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. 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. However, Android rootfs is able to boot to the desktop (v4403 3D accelerated) with tilt-tracking-android, and X can come up unaccelerated as usual as well on Ubuntu on tilt-tracking. So it's not a bad start. When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 23 June 2011 08:51, Andy Green andy.gr...@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 introduced two new branches yesterday: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking-android - 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-rclatestand move them to 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? ~Deepak ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 06/23/2011 05:04 PM, Somebody in the thread at some point said: On 23 June 2011 08:51, Andy Greenandy.gr...@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;a=shortlog;h=refs/heads/tilt-tracking - omap4_defconfig http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-tracking-android - 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-rclatestand 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 -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On Thu, 23 Jun 2011, Andy Green 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. $ 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. 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. So I'm asking people for comments about this tree. - Is this useful? - Is it important? - Are _you_ using it? - 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. 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? 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. Opinions anyone? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
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 -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On Thu, Jun 23, 2011 at 2:39 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 23 Jun 2011, Andy Green 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. $ 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. 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. So I'm asking people for comments about this tree. - Is this useful? - Is it important? - Are _you_ using it? - 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. 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? 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. Opinions anyone? +1 We are still a few patches away (about 85 at my last count) from having a good experience on the mainline with the BeagleBoard-xM. I want to see that count reach 0, hopefully by whatever is next after 3.0. No out-of-mainline patches has to be the goal. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
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 thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
Hi John, On 24 June 2011 00:14, john stultz johns...@us.ibm.com wrote: 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 Yes that fix the issue. Though the responsible part is inadvertently dropped TLL initialization. Thanks, Jassi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On 23 June 2011 11:39, Nicolas Pitre nicolas.pi...@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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org
