Hi all,
For kernel guys and landing teams, I've posted some kernel-specific
info on mirating to Thumb-2 here:
https://wiki.linaro.org/WorkingGroups/Kernel/Thumb2Guide
If your kernel tree isn't building in Thumb-2 yet, please do take a look.
Let me know if you want more information on anything, or if you find
something that's incorrect or confusing.
Cheers
---Dave
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…
(Apologies for any duplication, googlegroups needs mail sent from Google
mail)
--
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
Hi all,
I want to give everyone a heads up about the kernel.org outage. As
most of you know, kernel.org was compromised by an outside hacker and
has been taken down for rebuild. You can find the coverage on
lwn.net[1][2][3].
[1] http://lwn.net/Articles/457142/ - Initial notice
[2] http://lwn.net/Articles/458809/ - Further details
[3] http://lwn.net/Articles/460376/ - An update from H. Peter Alvin
Because kernel.org is central to the kernel development process,
particularly since the majority of git trees pulled by Linus live
there, the security of kernel.org is of paramount importance. It is
critically important that when the kernel.org infrastructure comes
back up that it not be vulnerable to another attack, so as part of
rebuilding the infrastructure, all of the policies around how
developers access kernel.org as well as how Linus pulls maintainer
trees is under review.
The reason for this email is to give you a heads up about what you
should expect when kernel.org becomes live again. There is a strong
likelyhood that maintainers will need to start GPG signing branches
that they will ask Linus to pull. Nothing has been decided firmly
(indeed, we won't know until Linus himself makes a decision about what
he will accept), and it will definitely be a topic for the upcoming
Kernel Summit at the end of October. However, it is worth taking the
opportunity now to get familiar with GPG and to create a key for
yourself. The Debian developers among you will already be familiar
with this process, /even if you don't have a kernel.org account/. The
Debian keysigning page[4] is a good place to start reading.
[4] http://wiki.debian.org/Keysigning
I'll post more details as I learn them. In the mean time, you can
email me if you have any questions and I'll do my best to answer them.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
== Thomas Abraham <thomas-ab> ==
=== Highlights ===
* Submitted clkdev and device tree support patches for Samsung UART
controller driver.
* Submitted keypad and DMA device tree support patches with all
comments addressed.
* Started with device tree support of SDHCI controller driver.
=== Plans ===
* Submit device tree support for SDHCI controller driver.
* Submit device tree support for SPI controller driver.
* Submit device tree support for display driver.
=== Misc ===
* Was on leave on 30th September.
=== DT ===
* Submitted the v4 and v5 of imx6q patch series.
- Fold the gic_handle_irq (local to imx) support patch in the series.
It can be replaced by Marc Zyngier's global gic_handle_irq support
with a little rework if his PPI and MULTI_IRQ_HANDLER series gets
merged.
- Address Russell's comments, do not call do_IPI() and do_local_timer()
from C code.
- Change to 'select AUTO_ZRELADDR if !ZBOOT_ROM'
- Rebase to Barry's L2 suspend infrastructure
- Fold Sascha's merge-imx3-imx6 patch to get single zImage support for
imx3 and imx6 family
* Posted v5 of imx51/53 DT series to seek being merged in the coming
v3.2 merge window, so that we have a base to ask people to move
towards DT.
- Rebase onto imx-features branch
- Have devices in soc dtsi as "disabled" and explicitly enable the
ones in board dts as "okay"
- Utilize of_irq_init() infrastructure added by Rob Herring recently
=== Plan ===
* National Holidays Oct 3 ~ 7 (will check email occasionally)
--
Regards,
Shawn
== Linus Walleij linusw ==
=== Highlights ===
* Working on pin control and pinmux, iteration v9 of the
patch set sent out and the pin control git is now part
of linux-next
* Arnd looked at the ux500-timers, found embarrasing bugs,
I fixed them (hopefully) and re-requested the branch to be
pulled.
* Relaxing with the ARM Integrator, knowledge base for this
board now exists at this location:
http://www.df.lth.se/~triad/krad/integrator/
=== 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
* Find out what is wrong with attached devicetree on our
platform.
* 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.
* Hold off any further gpio.h cleanups until after the merge
window - we have created enough mess already as it is.
* Drive generalization of U300 and Nomadik GPIO
by using the pinctrl framework
* Watch the DBx500 PRCMU drivers update, pushed
Sam again today
* Watch struct clk generalization and movement of clk
drivers into drivers/clk
* Mainline some ux500 U-Boot stuff so it can atleast boot
the system. (Or is Niklas doing this?)
=== Issues ===
* Appended device trees does not work for us.
Still don't know why.
Thanks,
Linus Walleij
== Rajendra Nayak <rnayak> ==
== Highlights ==
* Reworked regulator dt support patches based on comments
from Mark/Grant. Waiting for a repost of the dependent i2c-twl
support series to resend it out for review.
* Started omap mmc driver dt migration. Will use auxdata to start
with for all the function pointers currently passed from pdata
* Study/review the pinmux/pinctrl series from Linusw.
== Plans ==
* Repost regulator dt support once i2c-twl series is out
* Post omap mmc dt patches, using regulator mappings from dt
* Use pinmux/pinctrl framework for OMAP
