Enclosed please find the link to the Weekly Status report
for the kernel working group for the week ending 2011-09-09.
== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-08
== Summary, for details see the Status Report ==
* Many Working Group members at Linux Plumbers Conference
* Rewrote the Freescale internal i.mx6q clock codes. With the common
pattern applied as much as possible, the LOC gets reduced to ~2K from the
original ~5K.
* submitted dt migrated patches(v2) for i2c controller along with generic
board files for omap3 and omap4
* Submitted second version of pl330 dma controller device tree support
patches.
* Submitted gpio and pinctrl device tree support patches for exynos4.
* Submitted gic and interrupt combiner controller device tree support
patches for exynos4.
* Submitted rtc device tree support patch for samsung's rtc driver.
* Started working on device tree support for exynos4 keypad controller
driver.
* Pushed out v6 of the pinctrl/pinmux subsystem.
* i.MX6Q (4 Cortex-A9 cores SMP) u-boot upstream preparation.
Best regards,
Mounir
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
Hello Loic,
(cc:ing list)
On Thu, 8 Sep 2011 13:26:57 +0200
Loïc Minier <loic.minier(a)linaro.org> wrote:
> On Thu, Sep 08, 2011, Paul Sokolovsky wrote:
> > Repo is bad tool for mirroring. We came to that conclusion, as other
> > folks before us. So, android-build repo mirror waits for it rewrite,
> > left in peace for now that it "mostly works". But for upstream
> > mirror for Gerrit, I implemented it via previously queued ideas of
> > "proper" git mirror. It's not deployed in production mode yet -
> > kernel.org downtime stroke right in the middle of it.
> >
> > Gerrit upstream mirror is essentially loop over existing working
> > repository tree in FS, anf git pull/push each with suitable ref
> > params (I tried --mirror first, but that doesn't work well with
> > Gerrit). The devel codxe is here:
> > https://code.launchpad.net/~linaro-infrastructure/linaro-android-gerrit-sup…
>
> It seems there is an important new problem with the use case of
> mirroring for Gerrit: detecting new projects and removed projects as
> to provision/unprovision in Gerrit (gerrit create-project). I guess
> we're not too strict about removing projects/cleaning up git repos
> removed from manifests right now.
Yes. Actually there're 2 problems: 1) detecting new upstream projects
(there's script for that, but not expected to be run automatically so
far); 2) properly migrating our own components to Gerrit, - so far we
just leave old repos in place to keep old releases fetchable, but I
expect this to lead to a mess. Btw, projects in Gerrit are not
deletable in normal way ;-). (One could hack on DB level, yeah.)
>
> Do I understand correctly that we have a mirror AND the Gerrit copy
> of the repos? (/srv/git.linaro.org/git/android + /mnt/gerrit-mirror
> respectively)
Yes, we have Gerrit-served master repositories, plus we have workcopy
checkout to perform merges with upstream. Well, those merges are not
merges, but fast-forwards of upstream branch subset, it would be cool
if git could do fast-forward from a repository to repository w/o
working copy, but of course that wouldn't work in general case of
merges and conflicts.
> Also, a general choice with a generic mirroring service is whether we
> try sharing the mirrored data effectively. Say we want to mirror
> Cyanogenmod manifests, or if someone wanted to mirror Android
> upstream
> + Linaro manigests, could we do so in a way which avoids duplicating
> the contents of repos.
> This can quickly jump to
> github/gitorious-level complexity though, but some of it needs to be
> considered now (like the fact that Linaro has plenty of manifests and
> they point at 99% of the same data, so a mirror of Linaro with
> separate storage per-manifest would be unacceptably costly).
I'm not sure I follow exactly. Are you talking about sharing git pack
data across repositories, knowing they're close forks of each other? I
never heard about that, nor I think its worth being pursued, because
there's enough complexity already. It can be handled on specific
project level somehow, for example Linaro codebase is a proper superset
of AOSP, with fetching Linaro tree, one would have (easily separatable)
access to both AOSP and Linaro code (technically, not politically).
> Another problem I see with our current usage is that the branch names
> keep changing, for instance linaro_android_2.3.5, and because this is
> where we get manifests from, it might be tricky hardcoding this into
> the mirroring service.
Good mirroring service wouldn't be tight to specific branch, I guess.
> > > I've solved c) by forking repo for myself, packaging it as
> > > a .deb and nuking the repo updating pieces, but a) and b) remain
> > > issues with the result. I have other concerns with repo:
> > > * quite complex and hairy for what it does in practice
> >
> > Yeah, just faced it that with latest "repo patched to fetch all
> > tags" campaign - seeminingly small changes broke mirroring and
> > suspectedly adversely affected performance.
>
> I didn't pull your patch yet, but my intent was to pull exactly that
> feature; it's the top three commits at:
> http://android.git.linaro.org/gitweb?p=tools/repo.git;a=shortlog;h=refs/hea…
> right?
Yes. Please note that I personally consider it flawed experiment. It
would have its limited usage, but to claim it's generally-suitable
solution, it would need lot of testing. (With all these experiments, I
got feeling that magic that repo does is very well thought, and keeps
acceptable performance when dealing with truly enormous Android codebase
at shaky equilibrium, so changing seemingly small thing can drop
checkout speed twice for example).
> > Yes, that's for sure a way to go. Except that after the patched repo
> > experiments I have suspicion that running repo against complete git
> > mirror vs repo's partial mirror may increase sync time and
> > I/O complexity (the latter hits in full in case of parallel
> > fetches).
>
> You're saying we should filter the contents of the git repos exposed
> in the resulting mirrored tree so that developers and buildds
> pointing repo at it get good performance, correct?
No, I'm saying that I have intuitive suspicions that it may affect
performance, so we'd rather take necessity of performance and load
tests for this work seriously. And if performance degradation against
reference design (repo) will be proven, think what to do about it.
> Do we know in
> which ways? avoiding useless branches I guess? If we know about all
> manifests which point at all branches/tags/shas, we can keep just
> that in the published repos and garbage collect the rest (might need
> more than git gc).
>
> > But generally, I came to following observation: 1) repo to fetch
> > codebase for development; 2) repo for mirroring; 3) repo to fetch
> > for quick build - are all rather different usecases. Usage 1 for
> > sure stays that way forever, but for usages 2 & 3 we may write
> > specialized tools providing better performance.
>
> Very well put!
>
> I agree on 1 and 2, I'm less sure about 3; would we really want to
> move to something else than repo for builds? It's good when buildd
> and developer builds look alike when possible.
Well, I don't know. We for sure would want to (try to) improve build
checkout time, and all ways should be considered. At repo is after just
a tool which checks out a list of git repositories at specified
revisions, so if we'd find more optimal way to do that (though likely
more limited in other aspects), why not?
> > > Another advantage is that there is now a python-git which can be
> > > leveraged rather than wrapping the git commands in python as repo
> > > does.
> > That sounds too complicated, like another "quite complex and hairy
> > for what it does in practice" ;-).
>
> Ah, so you've played with python-git and it sucks?
No, I didn't mean that. I meant that before moving to using more
intricate API level which would be allowed by using language binding,
it would makes sent to try to implement it in terms of git pull/push,
if that's not enough - git fetch, and only if still not enough - to
employ even more complex solutions.
> Fair enough, but
> I did find it's a bit of a pity that repo has so much git wrapping
> logic, not isolated at all, and probably fragile in the face of
> changes to the host's git and gitconfig.
>
> > I guess you know that Google works (worked) slowly on integrating
> > some kind of submodules support into repo (for exact purpose not
> > known by me, I assume ditching manifests, but maybe just to support
> > components with it). But works goes very slowly or halted.
>
> The whole repo workflow seems so borken to me that I doubt they have
> a chance fixing it in incremental updates.
>
> > Well, I can't at once tell if repositories with submodules may need
> > additional attention with mirroring. My guess is yes. After all,
> > submodule is just a symlink to another repo, they are fetched in
> > *working copy*. And git mirror is a bare repo.
>
> You're right; I hadn't thought enough about this. It will definitely
> need more than a couple of commands.
>
> First, we'll run in the same issue that required rewriting manifests
> that the sources for the commits are separate repos. So we could
> rewrite ".gitmodules" files, or we could try using "insteadOf" to map
> original URLs to mirrored URLs. Would be nice if this is easy to
> consume.
> Second, indeed we need to do the actual fetching, but it doesn't
> seem to be *too* hard; perhaps we could even contribute this to git
> if it's generic enough.
>
Yes, I guess that makes sense.
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Enclosed, please find a link to the agenda, notes and actions from the Linaro
Release Weekly meeting held on September 8th in #linaro-meeting on
irc.freenode.net at 16:00 UTC.
== Meeting Minutes ==
http://wiki.linaro.org/Cycles/WeeklyReleaseMeeting/2011-09-08
== Meeting Log ==
http://irclogs.linaro.org/meeting-logs/linaro-meeting/2011/linaro-meeting.2…
== Previous actions items ==
* Mounir to open the discussion with Michael Hope about Toolchain WG release
date. - DONE
Michael Hope agreed to change the Toolchain WG release scheme to two weeks
before Linaro release. It will give Developer Platform and Android Teams a
fixed two weeks between the toolchain and the platform release.
REMINDER: next Toolchain WG release is next Thursday (September 15th)
* james_w/pfalcon/fabo to follow-up closely on disk space issues, quote of
hardrive. - INPROGRESS
The drives have been ordered. They should be with us tomorrow
(September 9th).
== Agenda ==
* Current focus:
- the list of components delivered for this cycle is up-to-date - DONE
- the milestone pages for this cycle are created - DONE
- the blueprints are targeted to this cycle - DONE
- the blueprints have a headline and an acceptance criteria - INPROGRESS
See http://wiki.linaro.org/Cycles/1109/Release/Blueprints
* Weekly call for testing
It was sent to board owners this week. We're working on another approach,
trying to make it more efficient/useful.
lava-qatracker work is ongoing. An initial version is planned for this cycle.
* Release response team setup started
See https://wiki.linaro.org/Cycles/1109/Release/PointOfContacts
We don't have a full boards coverage yet. Android PoC are missing. Zach will
send his list soon.
* Reminder on the release dates
See http://wiki.linaro.org/Cycles/1109/Release/Status
It's available from the release dashboard:
http://wiki.linaro.org/Cycles/1109/Release/Dashboard.
In addition, the Release calendar is shared with everyone.
== Image status ==
* Ubuntu-build - no issues to report.
* LT Snowball hwpack is disabled in favor of V2 and V3 hpwacks.
* Linaro patched repo is dropped
* Android-build is stable now.
== Bugs ==
* http://bugs.launchpad.net/bugs/709245 High
ARM SMP scheduler performance bug
=> Tracked by jcrigby, we have a fix
* http://bugs.launchpad.net/bugs/732912 High
omapdss DISPC error: GFX_FIFO_UNDERFLOW
=> Tracked by mounir/doanac; fixed according to doanac
* http://bugs.launchpad.net/bugs/753878 High
Ubuntu image - icons and parts of screen disappear with Origen
=> Assigned to rsalveti, important to get fixed but no progress
* http://bugs.launchpad.net/bugs/754254 High
imx51 randomly truncates serial input at 31 characters
=> Spring can't verify because of 2 other bugs (see below)
* http://bugs.launchpad.net/bugs/788746 High
Ethernet is not enabled be default
=> Assigned to mpoirier, being worked on
* http://bugs.launchpad.net/bugs/789095
Bluetooth does not work on PandaBoard
=> Assigned to rsalveti
* http://bugs.launchpad.net/bugs/807230 High
ADB requires new userland setup w/ linux-linaro-android 3.0-2011.07
=> Assigned to vishal, being worked on
* http://bugs.launchpad.net/bugs/816491 High
System crashes when display attempts to sleep
=> Waiting for Andy Green, we need LT support on that
* http://bugs.launchpad.net/bugs/816638 High
Pulseaudio consumes 100% of the cpu when trying to play a sound with
natty's linaro LEB and 3.0.0-1402-linaro-lt-omap
=> Assigned to rsalveti, kan_hu is helping; in progress
* http://bugs.launchpad.net/bugs/823313 High
Android LEB fails to mount system and user partition interminttently
=> Assigned to philang, no progress, Anmar/Tony to get information on the bug
* http://bugs.launchpad.net/bugs/824506
Graphics driver on i.MX53 Android issues
=> Fix commited on Android userland, FSL may want to fix the driver
* http://bugs.launchpad.net/bugs/829220 Critical
linaro-media-create fails for snowball_emmc
=> Fixed but trigger another issue, mpoirier to comment
* http://bugs.launchpad.net/bugs/832356 High
LT-Panda 11.07/08 lacks device tree support
=> Assigned to rsalveti
* http://bugs.launchpad.net/bugs/832680 High
Make available source and debug packages corresponding to Linaro binary images
=> Assigned to rsalveti
* http://bugs.launchpad.net/bugs/839539
mx51evk can't load uImage and dtd from mmc card
=> Eric M. waiting for Spring response
* http://bugs.launchpad.net/bugs/839541
mx51evk can't find rootfs by UUID, LABEL or device node, then drop
to initramfs
=> Eric M. waiting for Spring response
* http://bugs.launchpad.net/bugs/841778
leb-origen failed to build for a couple days in a row
=> Assigned to Botao/Angus, Trigger bug 844380 and bug 844041, in progress
* http://bugs.launchpad.net/bugs/841781
no release builds for 11.09 have been set up yet
=> Zach will release builds for 11.09 soon
* http://bugs.launchpad.net/bugs/843628
perf failure on panda (omap4)
=> Assigned to Dave Long/aviksil
== Action items ==
* TLs/PMs to re-discuss weekly testing and comes up with a plan to improve
the situation.
* pfefferz/mansson_ /dzin to sort out the PoC for Android. It might need some
redefinition of who we need.
* fabo to drop all patched repo instance from the release websites, launchpad
and wiki.
== People present ==
fabo
pfefferz
rsalveti
mounir
mansson_
james_w
uahmad_
anmar
tgall_foo
ibiris
--
Fathi Boudra
Linaro Release Manager | Platform Project Manager
Linaro.org | Open source software for ARM SoCs
Thought people may find this information interesting.
I was going through all the changes that came in for each target as I
was cutting the first candidate builds of the 11.09 release. The From
is 11.08 and the To: is our release point: Here's each kernel:
The upstream build (works for Panda, Beagle xM and Beagle, would be
great to get basic support for Snowball, Origen and iMX53)
git://git.linaro.org/people/jstultz/android
From: c6952bc6d4a64535c31e22ab68c7d6a316ca717b
To: 312effedac183148411c965e20a62e73f23979f6
239 commits, Linux 3.0.3
grep -i:
OMAP
b0c1aa6 OMAP3: beagle: add support for beagleboard xM revision C
cbe2634 ARM: pm: omap3: move saving of the auxiliary control registers to C
46e130d ARM: pm: omap3: run the ASM sleep code from DDR
14c79bb ARM: pm: omap34xx: remove get_*_restore_pointer functions,
directly use entry points
076f2cc ARM: pm: omap34xx: convert to generic suspend/resume support
2637ce3 ARM: pm: omap34xx: remove misleading comment and use of r9
857c1b8 ARM: pm: omap34xx: no need to save all registers in sleep34xx.S
TI Staging
git://git.linaro.org/people/andygreen/kernel-tilt
From: f175e10ca2932083c40aa1adc54b0df625d37a89
To: 1d966243e9cf74d185cc7a070aff2987743ae234
This is:
default.xml
git://git.linaro.org/people/jstultz/android
From: c6952bc6d4a64535c31e22ab68c7d6a316ca717b
To: 312effedac183148411c965e20a62e73f23979f6
+
486 TI patches
git log --oneline
312effedac183148411c965e20a62e73f23979f6..1d966243e9cf74d185cc7a070aff2987743ae234
Includes non-upstream:
SYSLINK, TILER, SGX, iommu, ALSA, HDMI, BT, WiFi, clocks
Samsung Staging
git://git.linaro.org/people/angus/linux-linaro-3.0
From: e5673d390f718ef4517778aa8a34c3f1fb3fd59e
To: c4564b2e0f9b1df27689905693faadb68e35699d
This is:
default.xml
git://git.linaro.org/people/jstultz/android
From: c6952bc6d4a64535c31e22ab68c7d6a316ca717b
To: 312effedac183148411c965e20a62e73f23979f6
+
156 Samsung patches
git log --oneline
312effedac183148411c965e20a62e73f23979f6..c4564b2e0f9b1df27689905693faadb68e35699d
Includes non-upstream:
touchscreen, HDMI, USB, EXYNOS4, LCD
Freescale Staging
git://git.linaro.org/people/bernhardrosenkranzer/android-kernel-iMX53
No 11.09 update yet
Tip: 3d981d9418c53e3e1a079582088121c641588791
5b2e099 Merge branch 'upstream/linaro.38' into linaro-android.38
+
196 Freescale & Android team patches
ST Ericsson Staging
git://git.linaro.org/bsp/st-ericsson/linux-3.0-android-ux500
No 11.09 update yet
Tip: 2036fd76350799bb2b53b309d0ac6d60692fe890
1fc74af Merge branch 'zImage_DTB_append' of
git://git.linaro.org/people/nico/linux into linaro-3.0
+
821 ST Ericsson patches
