== Dave Martin <dmart> ==
=== Activity Summary ===
* Some more discussions around testing/quality/documentation and
use cases for the linaro deliverables.
* Some existential discussions around the meaning of __linux__,
which Android toolchains seem not to define, causing issues when building
against Linux headers. Possible solutions involve defining __linux__
explicitly from a top-level Makefile, or to introduce a new define
specifically to mean that the Linux kernel is being built. The
android team are now using a temporary solution based on the latter,
but the right fix still needs to be agreed.
* Useful meeting with Andy Doan and Matt Waddel about having a Connect
blueprint session on making Linaro documentation more useful and
accessible.
* Pinged for further feedback on AMBA module autoloading patches via
LKML.
* Moved office again.
* Still no significant progress on Versatile Express this week, due to
discussions and other work.
=== Plans ===
(On holiday next week.)
Move Versatile Express DT patches forward
Prepare for Linaro Connect
Prompt for further feedback on minor Thumb-2 randconfig issues:
* v6/v7 single kernel Thumb-2 undef fixup patches: currently waiting
for Russell/Arnd to comment
* Fixing some Thumb-2 related randconfig errors reported by Arnd:
* pxa/pj4/iwmmxt uses non-Thumb-2-compatible code: waiting for
feedback (probably needs a Marvell expert to comment)
* tegra2 uses non-Thumb-2-compatible code: waiting for feedback from
Colin Cross.
=== Work Items ===
(none this week)
=== Absences ===
Mon 2011-10-17 - Fri 2011-10-21
After talking with Andy and Alexander, I've re-merged the linaro-3.1
tree with Andy's android tracking tree (currently on 3.1), and am
switching to that as the base for the linaro-android-3.1 tree. Hopefully
this will assure that there is little difference as possible between the
linaro-android tree and Andy's android tracking tree (at least at this
moment - tracking trees don't stay still :).
I've tagged it as: linux-linaro-3.1-2011.10-0-android-1
>From the branch:
git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-agreen-rebase
Apologies to anyone who might have started basing work on the
-ozoom-rebase branch. There really should be minimal difference between
the two, and so it should be fairly easy to rebase any completed work
onto the new branch.
thanks
-john
Just a note to let you know that the linux-linaro-3.1 branch is now set
up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git;a=summarygit://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet,
however it should be really close. And the only addition I've
forward-ported from the linux-linaro-3.0 branch is the EHCI performance
fix from Ming Lei given that mainline doesn't appear to address this
issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as
I'm not sure what kernel base the consumers of the Linaro kernel are
going to settle on for their 11.10 release.
Nicolas
With Nicolas releasing the linux-linaro-3.1 branch, I wanted to also
announce that the linaro+android-3.1 branch has also opened.
I've tag it as: linux-linaro-3.1-2011.10-0-android-0
>From the branch:
git://android.git.linaro.org/kernel/linaro-android.git linaro-android-3.1-ozoom-rebase
Since android.git.kernel.org is still down, and there is no official
kernel/common-3.1 branch, I've merged in the forward ported
kernel/common-3.0 work done by TI in the omapzoom p-common tree. Thanks
to the TI folks for that work!
Let me know if there's any trouble. Similarly, I'll be following Nico's
linux-linaro-3.0 work in case the 3.1 jump is too aggressive for 11.10.
thanks
-john
Hi -
Recently at Linaro we've started a new tree
linaro-androidization-tracking, which is pretty much "common-3.1"[1] at
the moment on 3.1-rc8 basis.
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
We have already been running a kernel tree tracking Linus HEAD since
2.6.39, which has OMAP4 / Panda enablement stuff on top of Linus HEAD,
so we have some experience with the rough and tumble.
What we missed having was an "all year round" Androidization tree that
we could combine it with to casually create Android versions of the work
we were doing on Vanilla Linus HEAD basis. We used common-3.0 for that
for a while late in the kernel release cycle when it was tracking Linus
HEAD itself and that was great. But common-3.0 like the name suggests
is really a release tree, and it stops tracking at release, and a new
one starts up only late in the next kernel release cycle.
Actually, it would be a big advantage for many folks to not be doing
their Android kernel development on lagging releases, but by tracking
Linus HEAD. They would have access to latest stuff already and they
don't have to think about backport or later forwardport stuff to a new
release, it's constantly tracking HEAD and being adapted.
One side-effect of using this tracking methodology is if they want
release trees, they can just clone their tracking branch at the time
Linus HEAD is at a release point and bam, a hopefully fully working
release tree is there. Another very nice side-effect is they can do the
bulk of the work once on a Vanilla Linus HEAD basis, and get and Android
version of that work routinely by merging or rebasing in the
Androidization tree - instead of doing and validating work twice on
separate Vanilla and Android trees.
So linaro-androidization-tracking is our attempt at that Linus HEAD
Androidization tree, moving it on regularly and fixing breakage as it
happens throughout the cycle. It's generic same as common-, it should
be usable for any arch or board to Androidize a vanilla kernel that is
on the same Linus HEAD basis just by merge or rebase action.
It seemed this effort might be interesting for the guys that make the
common- trees, since if there was a tracking Androidization tree, in
fact common- releases for release trees like common-3.1 would just
naturally fall out of it when Linus HEAD was at 3.1. So I'd be very
happy to hear any opinions about that.
Another side-issue is we are also looking at refactoring the
Androidization patchset into topic branches, at the moment they're kind
of reflecting the history that they were applied on plus or minus some
munging around. So, all the net core patches for example would be
together in one series, then all the wireless ones in a series on top of
that, etc. It seems they would be easier to maintain then, opinions on
that approach are also welcome.
-Andy
[1] TI have a tree on omapzoom where we got the patches from
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi…
--
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
== Thomas Abraham <thomas-ab> ==
=== Highlights ===
* Submitted second version of UART and IRQ device tree support patches.
* Prepared a single device tree enabled board file for smdkv310 and Origen
boards and tested device tree support on both the boards for the following
modules: UART, SDHCI, Keypad, GPIO keys, DMA, RTC, I2C, WDT,
GPIO, IRQ
=== Plans ===
* Submit updated/rebased device tree support patches for SDHCI, Keypad,
DMA, RTC, GPIO, IRQ and dt-board file. (hoping that all of these will be
merged in 3.2)
=== Issues ===
* (Not critical) Testing for backward compatibility with the changes in the
drivers for all previous Samsung boards consumes lot of time.
== Linus Walleij linusw ==
=== Highlights ===
* Maturing pinctrl core and pinmux in linux-next, answering
late review comments and merging smaller patches.
* Arnd pulled the last ux500 stuff (timers) for the merge
window.
* Found the problem with attached device trees on my
platforms. Root cause: mismatched "compatible" node
hangs kernel 3.1+ at an early stage, with an error message
on the earlyprintk console. If you don't have a working
earlyprintk the stuff locks up, and this non-visibility of
early errors had us stuck for a while.
* Reviewed various stuff. (pinctrl, MMC, new platform called
SPMP8000).
=== Plans ===
* Let pin control core and pinmux mature in -next and
I expect to issue a pull request to Torvalds in the coming
merge window
* Start working on generic pin control:
- Biasing
- Driving
- Input modes
- Load capacitance
First step - survey of existing configuration options for
currens SoC:s.
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Drive generalization of U300 and Nomadik GPIO
by using the pinctrl framework
* Watch the DBx500 PRCMU drivers update, fixed
patches for Sam, but don't know if he's pleased with
them yet.
* Mainline some ux500 U-Boot stuff so it can atleast boot
the system.
=== Issues ===
* The formation of the clk subsystem seems pretty much
tangled up in details right now, don't know what to do
about it though :-(
Thanks,
Linus Walleij
Hi -
TI Landing Team has added a couple of new trees to our git repo over the
weekend
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=summary
Both of them track Linus HEAD, currently at 3.1-rc8.
First is "linaro-androidization-tracking", this is Linus HEAD plus a set
of Androidization patches formed from common-3.0 and common-3.1.
"common-3.1 you say?", yes, TI needed a tracking Androidization tree and
have made their own public one using pieces from common-3.1.
You can find TI's tree that was an ingredient in this here if you're
interested, it's public
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-androi…
Due to android.git.kernel.org down, AFAIK there's no public access to
common-3.1 direct otherwise at the moment.
So what's this tree good for? If you have a kernel for any arch or
board that is based on Linus HEAD, 3.1-rc8 at the moment, you can merge
or rebase a copy of it with linaro-androidization-tracking to create an
Android version of the same kernel.
That's very handy if you did your work to get stuff looking good on
Vanilla Linus HEAD and don't want to repeat the effort to get the same
features coming in an Android kernel.
Until now there was no way to casually Androidize a Linus HEAD basis
tree unless it happened common-3.x was tracking it, which it only does
for a short period at the end. It meant that you had to use old release
to start integrating and adding drivers for Android and backport from
HEAD anything nice that was coming. Now with this tree, you can do your
work on Linus HEAD and fork off working release trees when Linus HEAD
goes through a release.
This Androidization tree is generic and should be usable for any arch or
board, there's nothing TI specific in there. Why then is TI Landing
team announcing it / TI go to the effort of creating their original one
we based off? Nobody else in Linaro wanted to do the work to create and
maintain it, so we own it at the moment. We'll have to see how tough it
is to keep tracking Linus HEAD through the post-release patchstorm but
reviewing the Androidization patchset I'm cautiously optimistic.
I don't have any connection to Google guys who are basically doing the
same work on common-3.x, but it would be very cool to be able to
cooperate with them on bringing this Androidization patchset forward for
everyone's benefit.
The second branch is "tilt-android-tracking". This is our main tracking
branch tilt-tracking for Panda enablement we have been running for some
months combined with "linaro-androidization-tracking" above.
This gets you an effective Panda enabled "3.1 preview" kernel that we
have had for a while on Vanilla also on Android in an ongoing way.
Current status of it is
+ 1080p SGX acceleration
- Suspend borked
- WLAN borked
But we only generated it Sunday, we are working on those issues now.
Lastly TILT is also providing tracking versions of the Android autobuilt
Panda-LEB tarballs that are ready to use. These are the Autobuilt
tarballs with the kernel replaced with a tracking one by us. You can
find them linked from our git repo in tilt-android-tracking column of
the status table there.
-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
=== Highlights ===
* Worked on prototyping sched-flag based timer freezing. Initial rough
hack allowed a system to drop from 20-60 wakeups per second down to 0.7.
The hack is not really viable, so I'm continuing to research and refine
the idea to see how it could best be implemented.
* Pinged AmitK for ideas on how to measure power improvements.
* Resubmit merge_config.sh script to lkml. So far have had no feedback.
* Reviewed a rough initial patch by Dave Hansen that could be the start
of some ashmem-like functionality. Talked with him about some of the API
issues over lunch.
* Split up some blueprints for Mounir
* Met with PaulMck for lunch to sync up on current issues around my
wakelocks idea.
* Linaro Connect expenses went through! Yay!
=== Issues ===
* N/A
== Dave Martin <dmart> ==
=== Activity Summary ===
* More discussions around testing/quality/documentation
* Reworked AMBA module autoloading series to Do Things Properly using
the existing modpost framework. Posted patches; about 50% Acked.
* Thumb-2 kernel migration advice posted on wiki and linaro-dev.
* No significant progress on Versatile Express this week, due to
discussions and other work.
=== Plans ===
Prompt for further feedback on minor Thumb-2 randconfig issues:
* v6/v7 single kernel Thumb-2 undef fixup patches: currently waiting
for Russell/Arnd to comment
* Fixing some Thumb-2 related randconfig errors reported by Arnd:
* pxa/pj4/iwmmxt uses non-Thumb-2-compatible code: waiting for
feedback (probably needs a Marvell expert to comment)
* tegra2 uses non-Thumb-2-compatible code: waiting for feedback from
Colin Cross.
=== Work Items ===
Refined the workitems list for vexpress:
kernel-versatile-boad-description-and-implementation:
* [dave-martin-arm] Dynamic loading of AMBA device drivers (including
via DT) - implement and test: DONE
* [dave-martin-arm] Dynamic loading of AMBA device drivers (including
via DT) - repost: DONE
* [dave-martin-arm] Dynamic loading of AMBA device drivers (including
via DT) - Propose for merging: TODO
linaro-kernel-o-finish-thump2-support:
* [dave-martin-arm] to document what he needed to do get Thumb-2
kernel working for a new SoC: DONE
=== Absences ===
Mon 2011-10-17 - Fri 2011-10-21
