Greetings,
I've pushed the current linux-linaro tree to git://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 topic armlt-mmc lt_arm/tracking-armlt-mmc topic armlt-arm-arch-fixes lt_arm/tracking-armlt-arm-arch-fixes topic armlt-misc-fixes lt_arm/tracking-armlt-misc-fixes topic armlt-ubuntu-config lt_arm/tracking-armlt-ubuntu-config topic armlt-android-config lt_arm/tracking-armlt-android-config topic armlt-gator lt_arm/tracking-armlt-gator # topic ufs svenkatr/ufs-for-linux-linaro topic emmc svenkatr/emmc-for-linux-linaro topic thermal_exynos4_imx6 amitdanielk/thermal_exynos4_imx6_work topic unsorted ynk/tracking-orphan-unsorted # Samsung LT topics: topic samslt-base lt_samsung/topic/base topic samslt-asv_cpufreq lt_samsung/topic/asv_cpufreq samslt-base topic samslt-audio lt_samsung/topic/audio samslt-base topic samslt-bl lt_samsung/topic/bl samslt-base topic samslt-cma_v24 lt_samsung/topic/cma_v24 samslt-base topic samslt-core lt_samsung/topic/core samslt-base topic samslt-dt lt_samsung/topic/dt samslt-base topic samslt-dummy_reg lt_samsung/topic/dummy_reg samslt-base topic samslt-fb lt_samsung/topic/fb samslt-base topic samslt-gadget lt_samsung/topic/gadget samslt-base topic samslt-hdmi lt_samsung/topic/hdmi samslt-base topic samslt-led lt_samsung/topic/led samslt-base topic samslt-mali lt_samsung/topic/mali samslt-base topic samslt-pd lt_samsung/topic/pd samslt-base topic samslt-rtc lt_samsung/topic/rtc samslt-base topic samslt-s2ram lt_samsung/topic/s2ram samslt-base topic samslt-touch lt_samsung/topic/touch samslt-base topic samslt-wlan lt_samsung/topic/wlan samslt-base
And the remotes are: # # remote <remote name> <remote URL> # remote lt_arm git://git.linaro.org/landing-teams/working/arm/kernel.git remote pmg_rob_lee git://git.linaro.org/people/rob_lee/linux.git remote svenkatr git://github.com/svenkatr/linux.git remote amitdanielk git://git.linaro.org/people/amitdanielk/linux.git remote android_jstultz git://git.linaro.org/people/jstultz/android.git remote ynk git://git.linaro.org/people/ynk/linux-linaro-tracking.git remote upstream git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git remote lt_samsung git://git.linaro.org/landing-teams/working/samsung/kernel.git
Thanks, Andrey
On Wed, Apr 18, 2012 at 02:16:19AM +0400, Andrey Konovalov wrote:
- tracking-umm-3.3-wip: this one seems to be in v3.4-rc3 mainline
tree, correct?
Not really -- that is an amalgamation of a number of patches, of which only the dma-mapping and some dma-buf changes went into -rc1/2. But what you really want to say is Sumit needs to respin the tree.
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 , 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.
-Andy
On Wed, Apr 18, 2012 at 3:04 AM, Andy Green 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 , 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. 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.
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.
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.
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
On Wed, Apr 18, 2012 at 7:39 PM, Andy Green andy.green@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.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.
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,
On 04/19/2012 08:53 AM, Somebody in the thread at some point said:
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.
I'm not sure I made the problem clear enough.
If you guys decide to include CMA series try #999 in your combined tree, the LTs have to make sure their kernels work with CMA #999 before you can combine them.
Because if LT#1 has CMA #1234 and LT#2 has CMA #4567, you can't combine them, they'll conflict all over with mutually exclusive resolutions. There's no way to solve the conflict that satisfies both kernels (and any on the CMA #999 you actually want).
Bearing that in mind, the LTs need access to a flavouring tree with CMA #999 in it (along with any other mandatory series) beforehand so they can work on aligning and testing their kernel to your mandated version, so they will all offer kernels with CMA#999, and you can combine them and get them all coming on CMA #999.
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.
It's not hard to solve - just publish the flavouring tree, it anyway exists as part of Andrey's flow.
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.
This topic dropping thing is not gonna be very useful, on our tree anyway. Most things depend on something else, like DSS -> HDMI -> (HDMI audio / HDMI audio 5.1), DSS + CMA -> omapdrm. Unless it's an endpoint, it won't come out.
If stuff wants ejecting because it patches mmc core and now will infect other LT trees with that, well, if it's mmc boot, just pull the whole tree, presumably they need those patches to boot.
All the time this gets talked about but nobody has actually merged all the trees, is wasted time (four months + now)
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.
The way forward is to align the LTs using the linux-linaro flavouring tree to provide mandatory versions of patch series used by more than one LT kernel.
It's that which is stopping casual merging of multiple LT trees.
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?
This topic exclusion thing is a red herring.
- align the patch series used by multiple trees by providing central, definitive version in linux-linaro flavouring tree
- get the LTs - if it's practical for them, sometimes it can actually be impossible, it which case accept they're sitting this one out - to align on the mandatory version
- just combine the trees already! What I did is make the LT trees single fat topics each in the combined tree, used my existing tools to do serialized rebase. It took a lot of real time to bind them since it thousands and thousands of patches.
- If stuff's busted, post on lists and tell LT about what's needed to do, eg
- Your tree with Mali driver in doesn't build with Mali deconfigured, could you sort that out?
- diffstat says your tree craps all over ./kernel... or ./drivers or core mmc code - what's that about?
- your tree says that driver for your SoC asset is default y, but it does not depend on your SoC configured in, can you fix that?
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.
Take the case every other LT is in there... our last 3.3 build is 2100 patches ahead of v3.3. I guess we're at a world record right now but still, with 4 LTs in there why am I rebasing all this junk all the time when I just want to get my kernel working with the mandatory components. Just give me a little tree with the mandatory components. When it's working, we can combine them from the starting point that the kernel worked with the same flavouring before unification, so any problems are coming from the other trees / unification action.
Don't forget just because other LT tree is in this combined tree does not mean it's saintly, it just means nothing combined with it yet that blew chunks because it conflicted with that tree's badness.
We need to separate out the process of aligning with mandatory series on our tree alone, and the process of interoperation with other trees.
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.
I hope this lengthy reply has helped us converge.
-Andy
On Thu, Apr 19, 2012 at 5:27 AM, Andy Green andy.green@linaro.org wrote:
On 04/19/2012 08:53 AM, Somebody in the thread at some point said:
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.
I'm not sure I made the problem clear enough.
If you guys decide to include CMA series try #999 in your combined tree, the LTs have to make sure their kernels work with CMA #999 before you can combine them.
Because if LT#1 has CMA #1234 and LT#2 has CMA #4567, you can't combine them, they'll conflict all over with mutually exclusive resolutions. There's no way to solve the conflict that satisfies both kernels (and any on the CMA #999 you actually want).
Bearing that in mind, the LTs need access to a flavouring tree with CMA #999 in it (along with any other mandatory series) beforehand so they can work on aligning and testing their kernel to your mandated version, so they will all offer kernels with CMA#999, and you can combine them and get them all coming on CMA #999.
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.
It's not hard to solve - just publish the flavouring tree, it anyway exists as part of Andrey's flow.
I talked to Andy and I agree that pushing the state of our linux-linaro tree _after_ the WG topics were merged but _before_ all the LT topics go in as a "mandatory" branch would offer a nice option to consume just our core subset of changes. So far I thought the topics alone would be good enough, but I understand the value of having a one shot core tree for some of the participants in the linux-linaro effort.
Also, I agree that we already have that state while merging topics anyway, so making that available should be really cheap - especially if we are OK that that "mandatory" branch (linux-linaro-tracking-core) will not be validated and released independently, but only be made available to make consuming our linaro core kernel work easier.
Andy and me seem to be aligned on that point and there was agreement that validating just the core set without enablement wouldn't be expected.
Ultimately I like the idea of establishing all or a subset of WG topics as the "linaro mandatory" set that the LTs have to converge around... this includes making decisions on what CMA version everybody should use.
With that I would say: let's do it.
Andrey/Ricardo: do you agree? Can we make such a "linux-linaro-tracking-core" branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics? At best we could sneak that service in for todays release candidate?
Happy to talk offline if there are questions/doubts etc.
On 04/19/2012 03:07 PM, Alexander Sack wrote:
On Thu, Apr 19, 2012 at 5:27 AM, Andy Green <andy.green@linaro.org mailto:andy.green@linaro.org> wrote:
On 04/19/2012 08:53 AM, Somebody in the thread at some point said: >> 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. I'm not sure I made the problem clear enough. If you guys decide to include CMA series try #999 in your combined tree, the LTs have to make sure their kernels work with CMA #999 before you can combine them. Because if LT#1 has CMA #1234 and LT#2 has CMA #4567, you can't combine them, they'll conflict all over with mutually exclusive resolutions. There's no way to solve the conflict that satisfies both kernels (and any on the CMA #999 you actually want). Bearing that in mind, the LTs need access to a flavouring tree with CMA #999 in it (along with any other mandatory series) beforehand so they can work on aligning and testing their kernel to your mandated version, so they will all offer kernels with CMA#999, and you can combine them and get them all coming on CMA #999. > 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. It's not hard to solve - just publish the flavouring tree, it anyway exists as part of Andrey's flow.
That's why I've changed the topics merge order last night:
On 04/19/2012 12:22 AM, Andrey Konovalov wrote:
Changes to the previous version:
- topics merge order changed: generic topics first, LT's topics last:
I talked to Andy and I agree that pushing the state of our linux-linaro tree _after_ the WG topics were merged but _before_ all the LT topics go in as a "mandatory" branch would offer a nice option to consume just our core subset of changes. So far I thought the topics alone would be good enough, but I understand the value of having a one shot core tree for some of the participants in the linux-linaro effort.
Also, I agree that we already have that state while merging topics anyway, so making that available should be really cheap - especially if we are OK that that "mandatory" branch (linux-linaro-tracking-core) will not be validated and released independently, but only be made available to make consuming our linaro core kernel work easier.
Andy and me seem to be aligned on that point and there was agreement that validating just the core set without enablement wouldn't be expected.
Ultimately I like the idea of establishing all or a subset of WG topics as the "linaro mandatory" set that the LTs have to converge around... this includes making decisions on what CMA version everybody should use.
With that I would say: let's do it.
Andrey/Ricardo: do you agree? Can we make such a "linux-linaro-tracking-core" branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics?
Sure :) With just one difference probably. Shouldn't this "linux-linaro-tracking-core" branch be mainline tip based, not just the most recent -rc? (So it would be the "real" tracking tree.) I also planned to have a "linux-linaro-tracking" branch to be exactly the same "linux-linaro-tracking-core" branch plus the current LT's topics for the next linux-linaro release. The "linux-linaro-tracking*" branches would be for new work being done (like moving to new CMA version), while the linux-linaro branch would be used mostly for testing and bug fixing. When we see that the "linux-linaro-tracking" is good enough, we move "linux-linaro" to it (rebasing to the nearest -rc if necessary). This implies that two versions of the topics must be supported: the "current" (use the same -rc as linux-linaro) and the "next" (mainline tip based) ones. Guess the WGs and the LTs are already doing something similar anyway.
At best we could sneak that service in for todays release candidate?
We probably could. But this has very little value for the current 12.04 release. Having "linux-linaro-tracking-core" *well before* the 12.05 release is much more important than right before the 12.04. That's why we could consider the "linux-linaro-tracking*" branches to follow the mainline tip more closely than with per -rc "granularity".
Happy to talk offline if there are questions/doubts etc.
OK
Thanks, Andrey
On Thu, Apr 19, 2012 at 4:21 PM, Andrey Konovalov < andrey.konovalov@linaro.org> wrote:
On 04/19/2012 03:07 PM, Alexander Sack wrote:
On Thu, Apr 19, 2012 at 5:27 AM, Andy Green <andy.green@linaro.org mailto:andy.green@linaro.org**> wrote:
On 04/19/2012 08:53 AM, Somebody in the thread at some point said:
>> OK, so this is a major change to what linux-linaro was before. > > While this is different, it's not entirely different from what wehad > 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.
I'm not sure I made the problem clear enough.
If you guys decide to include CMA series try #999 in your combined tree, the LTs have to make sure their kernels work with CMA #999 before you can combine them.
Because if LT#1 has CMA #1234 and LT#2 has CMA #4567, you can't combine them, they'll conflict all over with mutually exclusive resolutions. There's no way to solve the conflict that satisfies both kernels (and any on the CMA #999 you actually want).
Bearing that in mind, the LTs need access to a flavouring tree with CMA #999 in it (along with any other mandatory series) beforehand so they can work on aligning and testing their kernel to your mandated version, so they will all offer kernels with CMA#999, and you can combine them and get them all coming on CMA #999.
> 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.It's not hard to solve - just publish the flavouring tree, it anyway exists as part of Andrey's flow.
That's why I've changed the topics merge order last night:
On 04/19/2012 12:22 AM, Andrey Konovalov wrote:
Changes to the previous version:
- topics merge order changed: generic topics first, LT's topics last:
I talked to Andy and I agree that pushing the state of our linux-linaro
tree _after_ the WG topics were merged but _before_ all the LT topics go in as a "mandatory" branch would offer a nice option to consume just our core subset of changes. So far I thought the topics alone would be good enough, but I understand the value of having a one shot core tree for some of the participants in the linux-linaro effort.
Also, I agree that we already have that state while merging topics anyway, so making that available should be really cheap - especially if we are OK that that "mandatory" branch (linux-linaro-tracking-core) will not be validated and released independently, but only be made available to make consuming our linaro core kernel work easier.
Andy and me seem to be aligned on that point and there was agreement that validating just the core set without enablement wouldn't be expected.
Ultimately I like the idea of establishing all or a subset of WG topics as the "linaro mandatory" set that the LTs have to converge around... this includes making decisions on what CMA version everybody should use.
With that I would say: let's do it.
Andrey/Ricardo: do you agree? Can we make such a "linux-linaro-tracking-core" branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics?
Sure :) With just one difference probably. Shouldn't this "linux-linaro-tracking-core" branch be mainline tip based, not just the most recent -rc? (So it would be the "real" tracking tree.) I also planned to have a "linux-linaro-tracking" branch to be exactly the same "linux-linaro-tracking-core" branch plus the current LT's topics for the next linux-linaro release. The "linux-linaro-tracking*" branches would be for new work being done (like moving to new CMA version), while the linux-linaro branch would be used mostly for testing and bug fixing. When we see that the "linux-linaro-tracking" is good enough, we move "linux-linaro" to it (rebasing to the nearest -rc if necessary). This implies that two versions of the topics must be supported: the "current" (use the same -rc as linux-linaro) and the "next" (mainline tip based) ones. Guess the WGs and the LTs are already doing something similar anyway.
Without thinking I would say that every branch (tracking, stable, etc.) and tag (release candidate, release etc.) should have the same -core subset explicitely marked.
At best we could sneak that service in for todays
release candidate?
We probably could. But this has very little value for the current 12.04 release. Having "linux-linaro-tracking-core" *well before* the 12.05 release is much more important than right before the 12.04. That's why we could consider the "linux-linaro-tracking*" branches to follow the mainline tip more closely than with per -rc "granularity".
My understanding is that it would help for Andy for this release. Can we just do the tags/branches?
On 04/19/2012 11:33 PM, Somebody in the thread at some point said:
Andrey/Ricardo: do you agree? Can we make such a "linux-linaro-tracking-core" branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics? Sure :) With just one difference probably. Shouldn't this "linux-linaro-tracking-core" branch be mainline tip based, not just the most recent -rc? (So it would be the "real" tracking tree.) I
That's the spirit ^^ Actually we found (with tilt patchload anyway) at start of kernel cycle, there is often heavy breakage coming from mainline HEAD day by day or even hour by hour. Keeping on top of that so you don't experience it all at once is really important.
But usually after the middle of the cycle, even trees that differ by two -rcs are basically compatible and can be merged / rebased pretty painlessly.
However... spare a thought for how this'll scale for you personally when you are dealing with say 10 LT trees each with 1000 patches.
When our tree hit 2100 patches (it should be half that at 3.4) it was taking hours to rebase, merging is not markedly faster. It's single-threaded so throwing more cores at it doesn't help.
It's another reason separating out -core flavouring uplevel and unified uplevel is the right path.
also planned to have a "linux-linaro-tracking" branch to be exactly the same "linux-linaro-tracking-core" branch plus the current LT's topics for the next linux-linaro release. The "linux-linaro-tracking*" branches would be for new work being done (like moving to new CMA version), while the linux-linaro branch would be used mostly for testing and bug fixing. When we see that the "linux-linaro-tracking" is good enough, we move "linux-linaro" to it (rebasing to the nearest -rc if necessary). This implies that two versions of the topics must be supported: the "current" (use the same -rc as linux-linaro) and the "next" (mainline tip based) ones. Guess the WGs and the LTs are already doing something similar anyway.
In tilt anyway we just have tracking and release-based branch. We do use tags now to give tracking a granular history. But there's no concept of -rc based sub-release atm. I guess you mention -rc basis because you're looking to make it a "rendezvous point" for combined tree, which is fair enough, although later in the cycle I found it's really accepting of quite a bit of deviation from exact same basis.
Generally, we only trash tracking once per cycle at the start when mainline undergoes its convulsion. The rest of the cycle, tracking should normally be tending to get better monotonically, since I don't normally push a new tree until it seems to be performing as well as what's in the repo already, unless there are special circumstances.
Without thinking I would say that every branch (tracking, stable, etc.) and tag (release candidate, release etc.) should have the same -core subset explicitely marked.
At best we could sneak that service in for todays release candidate? We probably could. But this has very little value for the current 12.04 release. Having "linux-linaro-tracking-core" *well before* the 12.05 release is much more important than right before the 12.04. That's why we could consider the "linux-linaro-tracking*" branches to follow the mainline tip more closely than with per -rc "granularity".My understanding is that it would help for Andy for this release. Can we just do the tags/branches?
No I did not mention anything about that. Today we only have half a tree undergoing a delayed rebase on 3.4-rc3+. That's running on its own timetable (ie, as fast as we can do it) that is completely disconnected to any monthly release action.
We need this -core thing not to speed us up for a monthly deadline but because existing approach isn't workable.
We better get used to the idea that now we want HEAD of everything (laudably) none of these trees, the LT ones, mainline, the mandatory source trees, none of them intrinsically care a fig about some random monthly release deadline and will only be in sync with what you want by occasional accident.
"Last known good" approach is not what you might think in this case either, since to combine them you'll have to revert all the trees to the same (or similar if late in the cycle) basis point, and for some LTs having to also revert to match the bad boy, that may be in worse state than their HEAD.
You'll sometimes only be able reissue "last known good" combined tree, not generate a new one at all. The combined tree has some "unique characteristics".
-Andy
On Thu, 2012-04-19 at 06:39 +0800, Andy Green wrote:
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?
I totally agree with Andy.
I don;t believe the common Linaro tree can work unless teams contributing to it know, and have access to, the common ingredient topics they depend on. This requires agreement, or at least an official announcement each month, of what version of a topic is going in; and for this to be done in good time for people to integrate, test and fix this.
If theses topics people depended on were also available in a pre-megered and tested flavouring branch then this would save duplicated effort and time.
(For the current ARM LT situation we have a simple life because we don't depend on anything other than mainline, but still, we could do better and earlier testing of our code and board if a Linaro flavouring topic was available.)
On Wed, 2012-04-18 at 02:16 +0400, Andrey Konovalov wrote:
Greetings,
I've pushed the current linux-linaro tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch.
This fails to build for vexpress because the Samsung Mali topic defaults to enabling Mali and UMP, they should probably default to being disabled and the Origen defconfig should enable them.
After editing drivers/gpu/arm/mali/Kconfig to make config MALI400MP 'default n', and similar with config UMP in drivers/gpu/arm/ump/Kconfig then things build OK.
The resulting kernel successfully booted an Oneiric desktop image I had from a couple of weeks ago.
Hi Tixy,
On 04/18/2012 01:24 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2012-04-18 at 02:16 +0400, Andrey Konovalov wrote:
Greetings,
I've pushed the current linux-linaro tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch.
This fails to build for vexpress because the Samsung Mali topic defaults to enabling Mali and UMP, they should probably default to being disabled and the Origen defconfig should enable them.
After editing drivers/gpu/arm/mali/Kconfig to make config MALI400MP 'default n', and similar with config UMP in drivers/gpu/arm/ump/Kconfig then things build OK.
The resulting kernel successfully booted an Oneiric desktop image I had from a couple of weeks ago.
Ok ... I will update the same in Samsung Mali topic.
Hi Tixy,
On 04/18/2012 01:28 PM, Tushar Behera wrote:
Hi Tixy,
On 04/18/2012 01:24 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2012-04-18 at 02:16 +0400, Andrey Konovalov wrote:
Greetings,
I've pushed the current linux-linaro tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch.
This fails to build for vexpress because the Samsung Mali topic defaults to enabling Mali and UMP, they should probably default to being disabled and the Origen defconfig should enable them.
After editing drivers/gpu/arm/mali/Kconfig to make config MALI400MP 'default n', and similar with config UMP in drivers/gpu/arm/ump/Kconfig then things build OK.
The resulting kernel successfully booted an Oneiric desktop image I had from a couple of weeks ago.
Ok ... I will update the same in Samsung Mali topic.
I have update topic/mali here. [1]
Can you please confirm if you wanted it that way?
On 17 April 2012 17:16, Andrey Konovalov andrey.konovalov@linaro.org wrote:
Greetings,
I've pushed the current linux-linaro tree to git://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
Tixy, will your tracking vexpress Android build use a older kernel version if this doesn't work ^^^^
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 topic armlt-mmc lt_arm/tracking-armlt-mmc topic armlt-arm-arch-fixes lt_arm/tracking-armlt-arm-arch-fixes topic armlt-misc-fixes lt_arm/tracking-armlt-misc-fixes topic armlt-ubuntu-config lt_arm/tracking-armlt-ubuntu-config topic armlt-android-config lt_arm/tracking-armlt-android-config topic armlt-gator lt_arm/tracking-armlt-gator # topic ufs svenkatr/ufs-for-linux-linaro topic emmc svenkatr/emmc-for-linux-linaro topic thermal_exynos4_imx6 amitdanielk/thermal_exynos4_imx6_work topic unsorted ynk/tracking-orphan-unsorted # Samsung LT topics: topic samslt-base lt_samsung/topic/base topic samslt-asv_cpufreq lt_samsung/topic/asv_cpufreq samslt-base topic samslt-audio lt_samsung/topic/audio samslt-base topic samslt-bl lt_samsung/topic/bl samslt-base topic samslt-cma_v24 lt_samsung/topic/cma_v24 samslt-base topic samslt-core lt_samsung/topic/core samslt-base topic samslt-dt lt_samsung/topic/dt samslt-base topic samslt-dummy_reg lt_samsung/topic/dummy_reg samslt-base topic samslt-fb lt_samsung/topic/fb samslt-base topic samslt-gadget lt_samsung/topic/gadget samslt-base topic samslt-hdmi lt_samsung/topic/hdmi samslt-base topic samslt-led lt_samsung/topic/led samslt-base topic samslt-mali lt_samsung/topic/mali samslt-base topic samslt-pd lt_samsung/topic/pd samslt-base topic samslt-rtc lt_samsung/topic/rtc samslt-base topic samslt-s2ram lt_samsung/topic/s2ram samslt-base topic samslt-touch lt_samsung/topic/touch samslt-base topic samslt-wlan lt_samsung/topic/wlan samslt-base
And the remotes are: # # remote <remote name> <remote URL> # remote lt_arm git://git.linaro.org/landing-teams/working/arm/kernel.git remote pmg_rob_lee git://git.linaro.org/people/rob_lee/linux.git remote svenkatr git://github.com/svenkatr/linux.git remote amitdanielk git://git.linaro.org/people/amitdanielk/linux.git remote android_jstultz git://git.linaro.org/people/jstultz/android.git remote ynk git://git.linaro.org/people/ynk/linux-linaro-tracking.git remote upstream git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git remote lt_samsung git://git.linaro.org/landing-teams/working/samsung/kernel.git
Thanks, Andrey
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, 2012-04-18 at 08:59 -0500, Zach Pfeffer wrote:
On 17 April 2012 17:16, Andrey Konovalov andrey.konovalov@linaro.org wrote:
[...]
- tracking-linaro-android-3.4: I've tried it with a smaller subset of the
Tixy, will your tracking vexpress Android build use a older kernel version if this doesn't work ^^^^
The tracking vexpress Android build isn't set to build daily and when it does, it builds the tip of the linux-linaro branch Andrey is putting together, so it will be in whatever state that is.
I have also been keeping the staging vexpress build up-to-date, which is John Stultz's linaro-android branch plus ARM LT topics. If someone accepts my manifest change in Gerrit, then that staging build will move over to Linux 3.4-rc3, which seems to work OK for me.
On 18 April 2012 09:24, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Wed, 2012-04-18 at 08:59 -0500, Zach Pfeffer wrote:
On 17 April 2012 17:16, Andrey Konovalov andrey.konovalov@linaro.org wrote:
[...]
- tracking-linaro-android-3.4: I've tried it with a smaller subset of the
Tixy, will your tracking vexpress Android build use a older kernel version if this doesn't work ^^^^
The tracking vexpress Android build isn't set to build daily and when it does, it builds the tip of the linux-linaro branch Andrey is putting together, so it will be in whatever state that is.
I have also been keeping the staging vexpress build up-to-date, which is John Stultz's linaro-android branch plus ARM LT topics. If someone accepts my manifest change in Gerrit, then that staging build will move over to Linux 3.4-rc3, which seems to work OK for me.
Done. Should we plan on releasing staging?
-- Tixy
On Wed, 2012-04-18 at 09:55 -0500, Zach Pfeffer wrote:
On 18 April 2012 09:24, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Wed, 2012-04-18 at 08:59 -0500, Zach Pfeffer wrote:
On 17 April 2012 17:16, Andrey Konovalov andrey.konovalov@linaro.org wrote:
[...]
- tracking-linaro-android-3.4: I've tried it with a smaller subset of the
Tixy, will your tracking vexpress Android build use a older kernel version if this doesn't work ^^^^
The tracking vexpress Android build isn't set to build daily and when it does, it builds the tip of the linux-linaro branch Andrey is putting together, so it will be in whatever state that is.
I have also been keeping the staging vexpress build up-to-date, which is John Stultz's linaro-android branch plus ARM LT topics. If someone accepts my manifest change in Gerrit, then that staging build will move over to Linux 3.4-rc3, which seems to work OK for me.
Done.
The change didn't get committed because the manifest was changed by someone else. I've uploaded a new change for review.
Should we plan on releasing staging?
It's a fallback, if the linux-linaro branch isn't working.
Greetings,
I updated (overwrote) the current linux-linaro tree (git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch).
Changes to the previous version: * topics merge order changed: generic topics first, LT's topics last: -----8<----- integration linux-linaro v3.4-rc3 ufs emmc thermal_exynos4_imx6 linaro-android-3.4 unsorted 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-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 samslt-android_config -----8<----- * Added tracking-linaro-android-3.4 topic: topic linaro-android-3.4 merge android_jstultz/linaro-android-3.4 * Added the fix from Samsung LT: no more build failures due to Mali and UMP on targets which don't have these devices. * samslt-rtc topic removed (it is in v3.4-rc3 already). * samslt-android_configtopic added. * omap4_defconfig added. Based on omap4_defconfig from 12.03 linux-linaro release. Doesn't belong to any topic yet, will go into the unsorted topic on the next linux-linaro update.
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. Or update the topic for v3.4-rc3. * the replacement for tracking-umm-3.3-wip (tracking-umm-3.4-rc3-wip probaly): haven't received the v3.4-rcX version so far.
Minimal boot test has been passed on the panda, though I had to use CONFIG_CLK_REG_CPUFREQ_DRIVER instead of CONFIG_ARM_OMAP2PLUS_CPUFREQ for the board to boot. Not sure if this is the right thing to do. Android testing is TBD.
Thanks, Andrey
On 04/18/2012 02:16 AM, Andrey Konovalov wrote:
Greetings,
I've pushed the current linux-linaro tree to git://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 topic armlt-mmc lt_arm/tracking-armlt-mmc topic armlt-arm-arch-fixes lt_arm/tracking-armlt-arm-arch-fixes topic armlt-misc-fixes lt_arm/tracking-armlt-misc-fixes topic armlt-ubuntu-config lt_arm/tracking-armlt-ubuntu-config topic armlt-android-config lt_arm/tracking-armlt-android-config topic armlt-gator lt_arm/tracking-armlt-gator # topic ufs svenkatr/ufs-for-linux-linaro topic emmc svenkatr/emmc-for-linux-linaro topic thermal_exynos4_imx6 amitdanielk/thermal_exynos4_imx6_work topic unsorted ynk/tracking-orphan-unsorted # Samsung LT topics: topic samslt-base lt_samsung/topic/base topic samslt-asv_cpufreq lt_samsung/topic/asv_cpufreq samslt-base topic samslt-audio lt_samsung/topic/audio samslt-base topic samslt-bl lt_samsung/topic/bl samslt-base topic samslt-cma_v24 lt_samsung/topic/cma_v24 samslt-base topic samslt-core lt_samsung/topic/core samslt-base topic samslt-dt lt_samsung/topic/dt samslt-base topic samslt-dummy_reg lt_samsung/topic/dummy_reg samslt-base topic samslt-fb lt_samsung/topic/fb samslt-base topic samslt-gadget lt_samsung/topic/gadget samslt-base topic samslt-hdmi lt_samsung/topic/hdmi samslt-base topic samslt-led lt_samsung/topic/led samslt-base topic samslt-mali lt_samsung/topic/mali samslt-base topic samslt-pd lt_samsung/topic/pd samslt-base topic samslt-rtc lt_samsung/topic/rtc samslt-base topic samslt-s2ram lt_samsung/topic/s2ram samslt-base topic samslt-touch lt_samsung/topic/touch samslt-base topic samslt-wlan lt_samsung/topic/wlan samslt-base
And the remotes are: # # remote <remote name> <remote URL> # remote lt_arm git://git.linaro.org/landing-teams/working/arm/kernel.git remote pmg_rob_lee git://git.linaro.org/people/rob_lee/linux.git remote svenkatr git://github.com/svenkatr/linux.git remote amitdanielk git://git.linaro.org/people/amitdanielk/linux.git remote android_jstultz git://git.linaro.org/people/jstultz/android.git remote ynk git://git.linaro.org/people/ynk/linux-linaro-tracking.git remote upstream git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git remote lt_samsung git://git.linaro.org/landing-teams/working/samsung/kernel.git
Thanks, Andrey
On Thu, 2012-04-19 at 00:22 +0400, Andrey Konovalov wrote:
Greetings,
I updated (overwrote) the current linux-linaro tree (git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch).
That builds OK for vexpress and boots Ubuntu. I also kicked off an Android build [1]
On Thu, 2012-04-19 at 10:22 +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2012-04-19 at 00:22 +0400, Andrey Konovalov wrote:
Greetings,
I updated (overwrote) the current linux-linaro tree (git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch).
That builds OK for vexpress and boots Ubuntu. I also kicked off an Android build [1]
Actually, it has a problem. Firefox can't resolve names or access the network, though ping from the command-line forks (and can resolve domain names.)
I also note in syslog that avahi-daemon can't start [1]
I'm pretty certain Firefox worked in the previous version of linux-linaro I tested a couple of days ago. Perhaps the Android topic has broken networking on Ubuntu.
On Thu, 2012-04-19 at 11:17 +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2012-04-19 at 10:22 +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2012-04-19 at 00:22 +0400, Andrey Konovalov wrote:
Greetings,
I updated (overwrote) the current linux-linaro tree (git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch).
That builds OK for vexpress and boots Ubuntu. I also kicked off an Android build [1]
Actually, it has a problem. Firefox can't resolve names or access the network, though ping from the command-line forks (and can resolve domain names.)
I also note in syslog that avahi-daemon can't start [1]
I'm pretty certain Firefox worked in the previous version of linux-linaro I tested a couple of days ago. Perhaps the Android topic has broken networking on Ubuntu.
This problem is due to CONFIG_ANDROID_PARANOID_NETWORK being enabled in Ubuntu as it defaults to 'y'. Editing configs/ubuntu.conf to add:
# CONFIG_ANDROID_PARANOID_NETWORK is not set
fixes the networking problem (after also fixing a compile error [1])
I note that some other Android configs default to 'y'...
CONFIG_HAS_WAKELOCK CONFIG_WAKELOCK CONFIG_USER_WAKELOCK CONFIG_NET_ACTIVITY_STATS
should we play safe and also disable these in Ubuntu?
Alternatively, it would be nicer if all of these defaulted 'n' and we got the Android config to enable them. (But that would mean carrying patches to AOSP code I guess.)
On 04/19/2012 04:03 AM, Jon Medhurst (Tixy) wrote:
On Thu, 2012-04-19 at 11:17 +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2012-04-19 at 10:22 +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2012-04-19 at 00:22 +0400, Andrey Konovalov wrote:
Greetings,
I updated (overwrote) the current linux-linaro tree (git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch).
That builds OK for vexpress and boots Ubuntu. I also kicked off an Android build [1]
Actually, it has a problem. Firefox can't resolve names or access the network, though ping from the command-line forks (and can resolve domain names.)
I also note in syslog that avahi-daemon can't start [1]
I'm pretty certain Firefox worked in the previous version of linux-linaro I tested a couple of days ago. Perhaps the Android topic has broken networking on Ubuntu.
This problem is due to CONFIG_ANDROID_PARANOID_NETWORK being enabled in Ubuntu as it defaults to 'y'. Editing configs/ubuntu.conf to add:
# CONFIG_ANDROID_PARANOID_NETWORK is not set
fixes the networking problem (after also fixing a compile error [1])
I note that some other Android configs default to 'y'...
CONFIG_HAS_WAKELOCK CONFIG_WAKELOCK CONFIG_USER_WAKELOCK CONFIG_NET_ACTIVITY_STATS
should we play safe and also disable these in Ubuntu?
Yea. All the android configs should be off for ubuntu.
Alternatively, it would be nicer if all of these defaulted 'n' and we got the Android config to enable them. (But that would mean carrying patches to AOSP code I guess.)
Yea. But we should be able to push items back to AOSP. I've not done it since they changed their gerrit system, so its probably a good exercise for me.
I'll try to queue them up, but until then I'd make sure its off in the ubuntu config.
thanks -john
On Thu, 2012-04-19 at 10:22 +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2012-04-19 at 00:22 +0400, Andrey Konovalov wrote:
Greetings,
I updated (overwrote) the current linux-linaro tree (git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch).
That builds OK for vexpress and boots Ubuntu. I also kicked off an Android build [1]
And that built and boots OK :-)
So I would say that we are good to use linux-linaro for this month's vexpress Android release.
That job used GCC4.6 but were using 4.7 for this month release, so I kicked the other build job [2] and made it build daily from now on.
-
Alexander Sack -
Andrey Konovalov -
Andy Green -
Christian Robottom Reis -
John Stultz -
Jon Medhurst (Tixy) -
Ricardo Salveti -
Tushar Behera -
Zach Pfeffer