On Wed, Apr 18, 2012 at 7:39 PM, Andy Green <andy.gr...@linaro.org> wrote: > 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.gr...@linaro.org >> <mailto:andy.gr...@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.
While this is different, it's not entirely different from what we had before. The major change here is that we're accepting a broader range of topics, but in the end it'll also depend a lot on what is currently being worked on by each LT and WG. > 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. I think that will depend a lot of the topic list and the respective content. While some topics are easy to identify as enablement, and with good possibilities to have conflicts or broken/bad solution, there's no simple way to classify topic types/groups. In the past we also wanted to publish most branches we could at linux-linaro, even from all the LTs, but unfortunately that didn't happen as expected and we ended up just with core changes. >> 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. This kind of conflicts will for sure happen once we start merging topics from different LTs. I believe we just need to make a clear statement on how we're planning to deal with conflicts, and how the LTs can use the current linux-linaro as based when checking for such conflicts, problems. From the maintainer pov it's hard to decide what to do in such cases. Currently we're working on a first-come, first-served model, and getting the list of branches/topics per WG and LT. Once we start having major conflicts, it'll be up to the maintainer to either drop both branches/topics, or select the one that looks more promising from the upstreaming pov. Without having a strong maintainer, that would work with the topic maintainers to find the best way to solve the conflicts, I don't think there's an easy way to get this going. At the same time, we'll be also publishing tools and pointers to every branch we're integrating and why, so the LT/WGs can use a subset while working on their topics until they can be integrated at the same basiline. > 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. But then how would you deal with the current topics list? How to identify which topics/branches we want to integrate at the common baseline? Would be enough if we publish the tools to do the branch/topics permutation for you to be able to validate your own work? >> 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". I don't see why we can't have both, and why enabling one LT would put the others in risk, if we're able to work together deciding what makes sense to be applied and what should be removed/re-worked. The current tree is still useful in many ways, and it also helps showing and getting the conflicts at the same time we have people working directly on them. With one strong maintainer, and enough discussions with the topic owners, I don't see that this tree will be useless to the point of being just a dump of what Linaro is currently working on. Get your list of topics, and check how it goes with the current tree. Test it yourself first, and then propose the branches/topics that you think it'd be useful to be integrated at the common baseline. That will help fixing the issues before going upstream, and getting the same enablement fixes across LT/WGs. You need to remember that this tree will be used and tested by mostly everyone working on kernel development inside Linaro. This will also be part of the LEBs and tested/verified by the QA team later on. Cheers, -- Ricardo Salveti de Araujo _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
