Hello everyone,
As I've been working on the integration of the latest developments and
fixes from upstream into the linaro-2.6.38 kernel lately, it became
quickly evident that major merge conflicts were to be expected. The
problem stems from the fact that we opened the 2.6.38 branch early i.e.
around the 2.6.38-rc5 kernel. Many patches that were merged into the
Linaro kernel have been subsequently modified by their respective
maintainers until they were merged upstream, meaning that what we have
now in mainline is different from what the Linaro kernel tree has. This
creates several issues:
- It is hard to verify that what is in the Linaro tree is actually the
latest and the best version of a patch.
- Merging additional fixes from upstream often ends up in merge
conflicts requiring manual resolution, sometimes non-trivial ones,
which is in itself a bug hazard.
- People wanting to contribute patches to the Linaro kernel potentially
have to create a different patch than what they would submit
upstream.
Given those issues, I decided to rebuild the linaro-2.6.38 branch from
scratch to see where that would bring me. And as could be expected, the
result looks nicer and it is much easier to work with than the current
tree. For example, this allowed me to merge the latest OMAP support
from mainline as is, including the latest fixes, without any need for
backport work nor major conflict resolution. Another advantage is that
the commit SHA1 references are now identical in most cases to what can
be found into mainline.
So... my question is: should we switch to this rebuilt tree or not?
There are drawbacks with such a move of course:
- All the testing done so far would be void. This is however not as
bad as this may look as the rebuilt kernel contains fixes for existing
bugs in the current tree, and the rebuilt kernel is using patches
that have and still are being tested by a wider community.
- I didn't forward port a couple series of patches that are available
in the current Linaro tree and not in mainline yet, including:
* DT support (Grant Likely)
* DVFS and PM for OMAP (Vishwanath Sripathy, Vishwanath BS)
* Some ux500 fixups (Linus Walleij)
* clock debug information (Yong Shen)
* Samsung CPUIDLE (Amit Kachhap)
So I would prefer if the people responsible for those patches did
resubmit their patches once they apply to the new tree (that should
be even easier now to apply patches that were meant for mainline).
- The history of the rebuilt tree is obviously different from the
current tree's. This means special care when updating to the new
tree with Git.
But overall I think there are more advantages than disadvantages for
such a move. What other people think?
The current rebuilt tree can be seen at:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.38.git;a=shortlog;h=…
or obtained from:
git://git.linaro.org/kernel/linux-linaro-2.6.38.git (the "rebuilt" branch)
Nicolas
== Device Tree ==
* Squash sdhci-pltfm-driver-self-registration series which becomes
one patch of sdhci-pltfm&OF-driver-consolidation series
* Sent a fec dt patch to fix build failure with pure non-dt kernel
* Tested dtb-append patch v3 from John Bonesio on mx51 babbage and
found non-dt kernel works fine, but dt kernel fails
== Misc ==
* Reviewed and tested fec improving patch from Lothar
--
Regards,
Shawn
== Jason Liu <Jasnliu> ==
=== Highlights ===
====DT====
* Work on the six step as Grant shows in the link:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-March/005024.html,
for the uboot part, I have already mailine it
for i.mx51 babbage board. As for other part, work is in progress.
I will send the whole patch set to grant soon.
====Kernel configuration ====
* NONE
====Misc====
* Some uboot patch upstream for bug fix which reported by FSL linaro
landing team.
1. mx53loco: set mmc env to MMC slot1:
http://lists.denx.de/pipermail/u-boot/2011-March/089000.html
2. fsl_esdhc: Fix multi-block read restriction on i.MX53 eSDHCv2:
http://lists.denx.de/pipermail/u-boot/2011-March/089023.html
* Kernel patch upstream for dmabounce bug fix.
* Cache coherency issue analysis and fix for i.mx51 SDIO driver.
=== Plans ===
* DT support for i.mx51/i.mx53 part.
===Issues===
* NONE
== Thomas Abraham <thomas_ab> ==
=== Highlights ===
* Submitted a basic device tree patch for smdkv310 board for inclusion
in smdkv310 hardware pack
* Submitted second version of prerequisite patchset for device tree
support on s5pv310
(http://www.spinics.net/lists/linux-samsung-soc/msg04439.html)
* Working on adding device tree based clock lookup code (based on
of_clock_add_provider)
=== Plans ===
* Submit a third version of s5pv310 dt patchset with clock lookup,
serial, watchdog and sdhci driver support.
=== Issues ===
* None.
== Kernel Development ==
* Reviewed drivers: MEI, cg2900, 23c2510, spear13xx-pcie
* Continued guiding the graduation of the IIO drivers from staging
== Flash memory ==
* Discussed about DRM features for SD cards
* Integrated results from flashbench-results mailing list into wiki
== Other ==
* Reinstalled my workstation with Natty
== Storage performance ==
=== mmc async (optimizations for dma) ===
* Tuned DT (http://www.scsifaq.org/RMiller_Tools/dt.html) together
with fault generation
in order to test error handling in mmc async implementation
* Fix bugs in mmc async implementation (ongoing)
=== mmc trim ===
* Extended trim test cases with secure erase and trim but write
performance (after trim) is still not as high as expected. I probably
need to go over the eMMC spec again to find my mistakes.
== Paul E. McKenney <paulmck> ==
=== Highlights ==
* Attended TSC meeting in Bangalore
* Pushed several more license approvals through the process.
== Issues ==
* -next testing located a bug in RCU priority boosting, which I am working.
Hello!
Please note that the earlier of the two calls will be at 8AM PDT
(3PM GMT, 4PM London time). The second of the two calls will be
12 hours later.
For other timezones, I recommend:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Thanx, Paul
I.e. does CONFIG_THUMB2_KERNEL imply ARMv7 or newer?
I assume this is the intent as arch/arm/Kconfig has
depends on CPU_V7 && !CPU_V6 && !CPU_V6K && EXPERIMENTAL
and there are no hits for the string "v6t" in the source tree
--
Tixy
