Hi -
Alexander was asking how linaro-androidization-tracking is maintained
(hope you are feeling better Alexander).
I made a 90-slide presentation about it at the last Connect, you can
find the slides here
http://people.linaro.org/~andygreen/lttools-introduction.pdf
and the tools here
http://git.linaro.org/gitweb?p=people/andygreen/lt-tools.git;a=summary
In a nutshell common-3.0 from Google is a history tree, so detecting new
patches on there is clear enough. John Stultz saw it had come back
recently and dropped me a note it had been updated. I asked Jassi to
isolate the new patches and send them to me.
I use lt-tools to distribute any new patches between the topics, then
reapply it to my android-ready branch and confirm it builds and works
before pushing.
lt-tools also takes care of the tracking action, it's important
everything is on the same Linus HEAD basis so I routinely rebase
linaro-androidization-tracking along with my other tracking branches, as
of last week it's on 3.2-rc4.
Actually, l-a-t is low maintainence since it's far from every day new
patches are coming on common-3.0, and so far on 3.2 cycle there was no
serious uplevel conflict between the androidization patch load and Linus
HEAD changes.
If we have someone else now who wants to maintain it, I think that's
fine with the provisos we should maintain the topic structure and look
at further refactor there, and we need a new approach to deal with
rebase points that more than one tree can rendezvous at --->
Right now when my tracking branches are in as reasonable a shape on one
Linus HEAD basis as they will get, I randomly pull a new basis from what
happens to be on Linus' tree that moment, and rebase everything on my
side against that (including up until now l-a-t at the same time). That
won't really scale to other LTs and WGs all randomly sampling Linus HEAD
at different random points as their basis.
Scott mentioned that there's a desire to see more KWG content at least
on tracking, I think that's a great idea. One way to solve both those
problems would be to no longer have LTs base off Linus HEAD but from a
new tree which is Linus HEAD + "linux-linaro-tracking", as it were, with
these other topics already merged in. So long as this rebases against
Linus HEAD really often, like daily at least in the early -rcs, carrying
its topic content with it, and matching linaro-androidization-tracking
is available, that would be a good way for all the LT trees to both get
any Linaro-specific content and increase their chances of having a
common "rendezvous" basis where multiple LT trees can be bound together.
-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
Includes some items from the short holiday week before
=== Highlights ===
* Sent out fadvise based ashmem alternative patch to lkml for review.
Got a decent writeup at lwn: http://lwn.net/Articles/468896/ as well as
decent feedback.
* Got a small fixes to the config_merge.sh script included in -mm
* Sent out patch queue for 3.3 (including the CLOCK_RATE removal patches
from Deepak). Tglx has yet to pull it, but I'll nag him again.
* Pushed a few fixes for 3.2 for RTC and clocksource issues. Were merged
into -tip.
* Reworked timekeeping cleanup/performance patches for Thomas
* Worked with Anton Vorontsov on background and plans for lowmemory
killer upstreaming.
* Chased some RTC, sched_clock and timekeeping related bugs.
* Good meetings with Android and CromeOS teams.
* Started reworking ashmem alternative idea from lkml feedback.
* Saw Greg KH has queued some android patches for staging again. Sent
email out to him to try to get a sense of what he's planning and looking
for.
=== Plans ===
* More reworking of the fadvise ashmem alternative. Try to integrate
akpm's mumble tree idea.
* Try to sort out some of the community bugs that i've been handling.
* Get xtime lock breakup patches submitted.
=== Issues ===
* Community issues been cropping up and taking more time then I'd like.
== Anton Vorontsov <cbou> ==
=== Highlights ===
* Got the first Linaro task: Android lowmemory driver upstreaming.
Familiarized with the lowmemorykiller code and requirements, investigation
on previous upstreaming efforts.
== Linus Walleij linusw ==
=== Highlights ===
* Sent out v5 of the pin config patch series after some further
discussion: as usual nVidia provide the most challenging
feedback.
* Discussed pinmux maps proliferation with Arnd Bergmann
and Haojian Zhuang (PXA pinmux maintainer) and came up
with patches to address the issue of being able to tag
pinmux maps as __initdata so they are discarded after boot.
We also added the possibility to incrementally add several
sets of pinmux mappings, doing away with the "once and
for all" approach to registering maps.
* Discussed DT mappings to pin controllers with Stephen
Warren and Tony Lindgren. No consensus reached.
* Ux500 mainlining since too little is happening:
- AB8500 RTC patches iterated with Andrew Morton and
accepted into his tree.
- Fixed up patches for some movearound in the abx500
include headers directory.
- Clean-up and forward-ported AB5500 high voltage
LEDs driver.
- The two latter will be sent off ASAP, just awaiting some
optional internal feedback.
* Read and commented on a few patches on various mailing
lists to keep uptodate.
=== Plans ===
* Drive generalization of Nomadik GPIO
by using the pinctrl framework.
drivers/gpio/gpio-nomadik.c
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
like the HWMON stuff.
=== Issues ===
* Risk of pin controller subimplementations being delayed due
to the time it takes to reach consensus. Would be good if
the people who really need the pin config stuff got involved
with the discussion and start ACK:ing patches when they
like them, and tell me what I'm doing wrong and if they agree
with the critics. Active participation in discussions would be
appreciated. NOTE: I'm worthless in soft motivational-aspects
of leadership (get people to actively do stuff). The only person
I can motivate to discuss pin control is myself...
Thanks,
Linus Walleij
Hi,
For those of you who did not attend the ELC/LinuxCon in Prague a few
weeks ago, the slides and videos are available here (just in case you
were not aware):
http://free-electrons.com/blog/elce-2011-videos/
Among them, you can find my LPAE/A15 presentation ("Linux Support for
the ARM Large Physical Address Extensions"), Lorenzo's "Consolidating
Linux Power Management on ARM Multiprocessor Systems" and Pawel's
"Linux on Non-Existing SoCs". Enjoy :)
--
Catalin
=== Device Tree ===
* Added device tree support for imx6 clock based common-clk-v3 series
and Grant's device tree binding series (RFC).
* Addressed Sascha's comments on imx6 clock DT support.
* Added mc13892-regulator device tree support based on Rajendra's
series which has been applied on regulator/for-next.
=== Consolidation and cleanup ===
* Reviewed Mike's common-clk-v3 series.
=== Misc ===
* Collected mxs saif-recording patches.
--
Regards,
Shawn
== Niklas Hernaeus <nhe> ==
=== General activity ===
* Prepared DT for knowledge sharing session.
* Knowledge sharing session on DT.
* Further planning for DT on Snowball.
== Rajendra Nayak <rnayak> ==
=== Highlights ===
* Regulator core DT support patches pulled in by Mark Brown.
Pushed to linux-next.
* Posted v2 of omap-serial DT support series with all outstanding
issues fixed.
* Working on pinconf support (pull up/down configuration) for OMAP
based on the latest v3 pinconf-core support series from LinusW.
Should have patches out early this week.
* Working on moving the omap clock data into DT based on the latest
clock bindings from Grant. Mike Turquette already has a port of
omap clock framework to use common clock infrastructure.
=== Plans ===
* Repost TWL regulator support. (Still waiting for a repost of omap
i2c/twl DT support patches)
* Work on pinconf/pinmux support for OMAP and align with Tony who is
working on moving the data into DT and creating function/pin-gp
information dynamically.
* Other driver DT support for OMAP.
== Linus Walleij linusw ==
=== Highlights ===
* Sent out v3 of the pin control patch set, along with the U300
reference implementation mentioned last week.
* Discussed pin properties v3 patch set, the compulsory generic
pin properties were shot down so I took them out and submitted
v4 where they are instead an optional feature:
http://marc.info/?l=linux-kernel&m=132216047021660&w=2http://marc.info/?l=linux-kernel&m=132216047121661&w=2
* Finalized discussion on GPIO range mappings when
using different directions, the solution is to support calls
for pinmux_gpio_direction_[input|output] as well.
Added short blurb to blueprint about it.
http://marc.info/?l=linux-kernel&m=132196330625742&w=2
* LWN has an article on pin control from Jon Corbet, yay!
* Harvested a single GPIO patch, will send to Torvalds
by pull request ASAP.
* Git my kernel.org linux-stericsson and linux-pinctrl repos
back online.
* Forwarded Rabins fix to Stultz' alarm timers:
* Ran an internal 30min presentation about kernel
consolidation going forward.
* Re-pushed AB8500 RTC patches with Andrew Morton on
To: since Alessandro Zummo is AWOL.
=== Plans ===
* Drive generalization of Nomadik GPIO
by using the pinctrl framework.
drivers/gpio/gpio-nomadik.c
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Pushed out the AB8500 HWMON driver, will try to address
review comments.
* Look into other Ux500 stuff in need of mainlining...
=== Issues ===
* Pretty much internal fuzz at my parent company due to re-
organization. Even more this week. And then some christmas
stress.
Thanks,
Linus Walleij
== Dave Martin <dmart> ==
=== Activity Summary ===
* Reviewing of Pawel's versatile express patches and related discussions
* Proposed a more unified approach for manipulating instruction opcodes
inside the kernel in the presence of multiple ISA and endianness
cofigurations.
* Started to sketch out a unified unwind/backtrace interface for the
ARM kernel (or, possibly, the whole kernel) in response to upstream
discussions regarding ftrace -- ftrace doesn't support unwind tables,
but really there should be a unified interface so nobody has to care.
* Reported a couple of binutils bugs
=== Plans ===
* Move miscellaneous outstanding DT issues (bindings, drivers) forward.
=== Work Items ===
https://blueprints.launchpad.net/linux-linaro/+spec/kernel-versatile-boad-d…:
* loading of AMBA device drivers (including via DT) - Propose for merging: DONE
=== Absences ===
(none planned)
