On 04/18/2012 08:39 PM, Somebody in the thread at some point said:
On Wed, Apr 18, 2012 at 3:04 AM, Andy Green <andy.green@linaro.org mailto:andy.green@linaro.org> wrote:
On 04/18/2012 06:16 AM, Somebody in the thread at some point said: Hi - > I've pushed the current linux-linaro tree > to git://git.linaro.org/kernel/linux-linaro-tracking.git <http://git.linaro.org/kernel/linux-linaro-tracking.git> , linux-linaro > branch. > > This is still work in progress, and it misses few topics. But due to > limited access to hardware at the moment it would be good to try it > sooner than later on vexpress and origen at least. (I have only panda on > hand). Minimal boot test has been passed on the panda, though I had to > disable CPUFREQ for the board to boot (haven't looked deeper yet). > > Not included are the following topics present in the 12.03 release: > * tracking-linaro_cpuidle: there are conflicts when rebasing it to > v3.4-rc3. The topic owner has been notified, and should tell me how to > proceed. > * tracking-umm-3.3-wip: this one seems to be in v3.4-rc3 mainline tree, > correct? > * tracking-linaro-android-3.4: I've tried it with a smaller subset of > the topics (w/o LT's ones), and it merged ok, but there are some > conflicts with the LT's stuff as it seems. Will have a deeper look > tomorrow. No action from John is required at the moment. > > Here is the list of the topic included into this tree currently: > # integration <name> <base> <topic1> <topic2> ... <topicN> > # - the merge order is <topic1> to <topicN>. > integration linux-linaro v3.4-rc3 ufs emmc thermal_exynos4_imx6 > linaro-configs-3.4 armlt-hdlcd armlt-mmc armlt-arm-arch-fixes > armlt-misc-fixes armlt-ubuntu-config armlt-android-config armlt-gator > samslt-base samslt-core samslt-bl samslt-dt samslt-fb samslt-pd > samslt-rtc samslt-s2ram samslt-asv_cpufreq thermal_exynos4_imx6 > samslt-led samslt-dummy_reg samslt-gadget samslt-touch samslt-wlan > samslt-audio samslt-hdmi samslt-mali samslt-cma_v24 unsorted > > Where the topics are: > # topic <local branch> <remote/branch> <topic base> > # - <base> must be another topic > # Example1: tracking-armlt-gator lt_arm/tracking-armlt-gator > # - missing <topic base> here assumes the mainline Linus tree. > # > # ARM LT topics: > topic armlt-hdlcd lt_arm/tracking-armlt-hdlcd ... > # Samsung LT topics: > topic samslt-base lt_samsung/topic/base > topic samslt-asv_cpufreq lt_samsung/topic/asv_cpufreq samslt-base ... What's the plan for this new linux-linaro approach of putting LT trees in there? Previously, until 3.2 when I tried to change base to it anyway, linux-linaro was like flavouring, it had a bunch of goodies we could add to our vanilla LT trees and we got Has it changed approach to be the combined tree now? So there is no longer a flavouring tree we can use to get the goodies from without having to deal with an increasing number of LT trees merged as well? (Or if it changed name to another branch, fine, but what is it) If so that will make things complicated to synchronize the LT trees you intend to bind here, to ensure they're all working with same UMM revision you mandate, etc before the binding.linux-linaro combines all topics that are registered and in our manifest. We don't restrict ourselves to non-enablement topics.
OK, so this is a major change to what linux-linaro was before.
I think you find it will have been better to stick with generating a separate flavouring tree without unification content, because you have created a chicken-and-egg situation now.
Actually, we always wanted enablement to be part of it and since we want to learn what that means we decided to pick up a few pilot enablement topics.
I guess the pure WG flavored tree you are looking for is not produced in a direct manner, but you can probably just pull in the topics from our linux-linaro manifest by stripping the other LT topics.
As I pointed out above, the issue is not that I happen to be looking for WG content, but that if you will bind together multiple LT trees they have to have a chance to converge on what ingredients you are mandating.
CMA is a good example, even in TI people have multiple trees with their stuff working only on particular versions of CMA series. Because I guess all the LT trees will currently have their own CMA, you stand no chance to bind them together in a unified tree unless they all agree to work on a single CMA version. It's not just CMA but other prerequisites like dmabuf, UMM pieces or whatever else is not-quite-in-mainline-yet. Sometimes that's turnkey but other times, uplevel in LT tree to what you want them to use may be nontrivial or involve politics or domain experts that don't want to do it. If it interacts with third-party code like 3D unit driver, it may not even be possible to do it on a given timescale for a given LT.
Since there will likely be multiple common ingredients like that, you need to provide the LTs with a flavouring tree for test so they can move towards sync against the mandated ingredient versions (hopefully, the latest stuff that works in each case). Otherwise, you don't give LTs a chance to converge or even test with your ingredients (not to mention forward planning so we can recruit help from domain experts at better than zero notice). That's the chicken-and-egg if your ingredients are only coming at post-unification tree how are we meant to prep our LT trees to combine smoothly?
Putting one LT tree in there (arm lt content is orthogonal to full tree) is the degenerate case that won't expose these issues.
Andrey will also produce a pinned manifest that gives you concrete info which commit from the individual topic branches got merged into the linux-linaro tree. This should make it feasible to extract just the subset you care about.
This is a subset I think you need to care about for the above reasons.
On the general point of conflicts through putting multiple hw enablement together: We have discussed a feature of "conflicting" topics that would mitigate the problem by producing a tree for each topic that has conflicts that leaves out the conflicting topics. At this point in time, we cannot handle conflicting topics yet ... our tools have to get in shape for that first and we expect to be closer to such a point by Connect.
Last: ultimately we hope that putting things together will ensure that we figure out how to stay aligned and non conflicting. I think it's an important exercise to go through and learn from.
Sticking one LT tree in there is not putting anything together.
Back in Dec I put 4 LT trees together and got interesting results (trees with mali in did not test it deconfigured, various other small issues about config defaults not making sense if SoC ARCH not also enabled, some LTs had mmc core code patches) but they were ignored. This effort at HEAD is great but you can enable the LTs to get ahead of the problems that are coming by doing what I did in Dec, a test combine of all LT trees at v3.3. Then we can say we are actually "putting things together".
-Andy