Greetings,
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies). This tree will be the basis for the next (12.05) linux-linaro kernel release. So if you have a topic to be added to 12.05 you can ask me to add it (the sooner you ask, the better), and it will appear in linux-linaro-core-tracking first. The request to add a topic must include the git tree location for me to pull the topic from, and the base used by this topic (mainline, or another topic). If no base for the topic is specified, the mainline is assumed. If needed, this is ok to rebase the topic; this would be easier for me to handle than e.g. reconfiguring my scripts to use topic-3.4rc5 branch instead of topic-3.4rc4 branch used so far etc. Again, starting from now this tree is open for the next release (12.05) topics. The linux-linaro-core-tracking tree is first of all to identify the conflicts early, so it could fail to build sometimes, or the kernel built from it may not boot etc. The plan is to rebase this tree on the current mainline tip daily. The topics causing the conflicts would be excluded from the linux-linaro-core-tracking tree, and would be brought back into it after the conflicts are resolved by the topic owners.
Thanks, Andrey
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi Andrey -
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies). This
Nice job, thanks for the new branch which definitely solves the "chicken-and-egg".
In fact it's going to be a great tracking "fake future upstream" staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide
I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 -> #24) and other little bits like Panda dt I could remove from our tree and use these common versions for. Otherwise it made very few conflicts compared to yesterday's Linus HEAD we were already on and the tree is as workable as it was.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=summa...
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
Although as I say our tracking is still missing some topics compared to tilt-3.3 as we are uplevelling, with this change of basis and elimination of CMA#21 delta we had until now, actually tilt-tracking can be considered for trial merge in unified tree I think. It's not very meaningful in terms of usefulness of our tree right now but it certainly should be interesting in terms of what makes trouble, if anything.
-Andy
On Tue, Apr 24, 2012 at 11:22 PM, Andy Green andy.green@linaro.org wrote:
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi Andrey -
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies). This
Nice job, thanks for the new branch which definitely solves the "chicken-and-egg".
In fact it's going to be a great tracking "fake future upstream" staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide
+1, hopefully that will make the LT life easier (specially yours, as you're maintaining tons of patches).
I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 -> #24) and other little bits like Panda dt I could remove from our tree and use these common versions for. Otherwise it made very few conflicts compared to yesterday's Linus HEAD we were already on and the tree is as workable as it was.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=summa...
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
We could just have the fragments per topic, and then the LT can decide either to add another fragment, or simply creating an entire different config to be used by default.
Having everything in config fragments may help automating the builds, but I understand that having one defconfig might also help people that are consuming the tree directly.
Cheers,
On 04/25/2012 11:12 AM, Somebody in the thread at some point said:
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
We could just have the fragments per topic, and then the LT can decide either to add another fragment, or simply creating an entire different config to be used by default.
Having everything in config fragments may help automating the builds, but I understand that having one defconfig might also help people that are consuming the tree directly.
Yes I'm not really referring to fragment process here, I understand the idea and as I wrote expect the common one(s) to come in with this base tree.
What I'm talking about is ./configs/panda.conf brought in by this
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=commi...
actually, now we don't maintain anything directly equivalent, we only have omap4plus_defconfig that builds a single kernel that runs with everything we support, including OMAP543x.
I guess panda.conf is trying to be mainline compatible OMAP44x0 Panda config. But what we're going to provide, and what's meaningful and tested with our tree, will be this omap4plus_defconfig that appears in our topics. panda.conf that we are inheriting from this basis branch may not even build with our tree, it's at least confusing to have it there and at worst it'll mislead end users, rot as we go on etc.
We can figure out how to apply ./configs/linaro-base.conf to omap4panda_defconfig and work with that. But panda.conf coming in at base tree is not meaningful and not tested on our tree, I think it and the other board confs coming in probably need to be removed from the basis tree and the LT minimal configs introduced in LT trees used instead.
-Andy
On 04/24/2012 08:24 PM, Andy Green wrote:
On 04/25/2012 11:12 AM, Somebody in the thread at some point said:
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
We could just have the fragments per topic, and then the LT can decide either to add another fragment, or simply creating an entire different config to be used by default.
Having everything in config fragments may help automating the builds, but I understand that having one defconfig might also help people that are consuming the tree directly.
Yes I'm not really referring to fragment process here, I understand the idea and as I wrote expect the common one(s) to come in with this base tree.
What I'm talking about is ./configs/panda.conf brought in by this
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=commi...
actually, now we don't maintain anything directly equivalent, we only have omap4plus_defconfig that builds a single kernel that runs with everything we support, including OMAP543x.
I guess panda.conf is trying to be mainline compatible OMAP44x0 Panda config. But what we're going to provide, and what's meaningful and tested with our tree, will be this omap4plus_defconfig that appears in our topics. panda.conf that we are inheriting from this basis branch may not even build with our tree, it's at least confusing to have it there and at worst it'll mislead end users, rot as we go on etc.
Yea, it was added mainly for demonstration purposes for how the config fragments might work. (It also is something I use for my panda on android testing, but that doesn't warrant it being included).
There may be some need for a config that the (oh the names have changed so much I don't know what its called) vanilla-upstream-android-builds-for-panda uses. But I'm happy to locate that somewhere else or with a more clear name.
Even so, if you and Andrey have a system that works for the omap config fragment, I'm fine dropping the configs/panda.conf
thanks -john
On 04/25/2012 07:12 AM, Ricardo Salveti wrote:
On Tue, Apr 24, 2012 at 11:22 PM, Andy Greenandy.green@linaro.org wrote:
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi Andrey -
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies). This
Nice job, thanks for the new branch which definitely solves the "chicken-and-egg".
In fact it's going to be a great tracking "fake future upstream" staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide
+1, hopefully that will make the LT life easier (specially yours, as you're maintaining tons of patches).
I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 -> #24) and other little bits like Panda dt I could remove from our tree and use these common versions for. Otherwise it made very few conflicts compared to yesterday's Linus HEAD we were already on and the tree is as workable as it was.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=summa...
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
We could just have the fragments per topic, and then the LT can decide either to add another fragment, or simply creating an entire different config to be used by default.
Agreed. This looks like something we should be moving to.
Having everything in config fragments may help automating the builds, but I understand that having one defconfig might also help people that are consuming the tree directly.
We could drop these defconfigs from linux-linaro-core-tracking while keeping them in the linux-linaro branch. One of the reasons for these defconfigs are the ci builds and tests: we must have the kernel configuration for every supported board in the tree. There is no requirement for this kernel configuration to be the defconfigs. It could be some script (in the tree) to produce the configs from the fragments, or whatever else.
Thanks, Andrey
On 04/25/2012 10:22 AM, Somebody in the thread at some point said:
Hi -
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
It doesn't seem to be android logger itself, just something else I always saw after Androidization, kernel logging that's anyway enabled to console by printk / loglevel is repeated without having it severity tag parsed off. That's objectionable now the basis is androidized and it still happens even with CONFIG_ANDROID off.
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
OMAP4 is booting again FWIW just a few dings to sort out.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
Looking closer at this, we prefer not to have CONFIG_MTD or CONFIG_JFFS in the base config. We don't really have a case for them on Panda.
You might want to push those out into a mtd.conf we will pass over, or something similar.
-Andy
Hi Andy,
On 04/25/2012 06:22 AM, Andy Green wrote:
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi Andrey -
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies). This
Nice job, thanks for the new branch which definitely solves the "chicken-and-egg".
In fact it's going to be a great tracking "fake future upstream" staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide
I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 -> #24) and other little bits like Panda dt I could remove from our tree and use these common versions for.
Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch. In fact, you've made a good point, and I'll probably just stop merging the tracking-unsorted into linux-linaro-core-tracking. This unsorted stuff is mostly "orphaned" commits from very old linaro kernel releases and the "last minute before the release" fixes. In a perfect world this unsorted topic just shouldn't exist.
Otherwise it made very few conflicts compared to yesterday's Linus HEAD we were already on and the tree is as workable as it was.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=summa...
Great!
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
No, it wasn't. In the Android patchset all their new config options are "y" by default, regardless of CONFIG_ANDROID even. We (well, John Stultz) have started changing these defaults to "n", and to enabling them in configs/android.conf (the WAKELOCK ones, ANDROID_PARANOID_NETWORK, and NET_ACTIVITY_STATS).
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree,
yes (this comes from the "unsorted" topic wich I am going to drop from this tree) ...
but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
...and yes
Although as I say our tracking is still missing some topics compared to tilt-3.3 as we are uplevelling, with this change of basis and elimination of CMA#21 delta we had until now, actually tilt-tracking can be considered for trial merge in unified tree I think. It's not very meaningful in terms of usefulness of our tree right now but it certainly should be interesting in terms of what makes trouble, if anything.
Very good. I was thinking about creating (reusing actually) linux-linaro-tracking branch to be the linux-linaro-core-tracking plus the LT's topics. But I still have quite a long TODO list, and linux-linaro-core-tracking and linux-linaro branches are higher priorities for me. So no commitments WRT linux-linaro-tracking at the moment :)
Thanks, Andrey
On 04/25/2012 09:54 PM, Andrey Konovalov wrote:
Hi Andy,
On 04/25/2012 06:22 AM, Andy Green wrote:
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi Andrey -
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies). This
Nice job, thanks for the new branch which definitely solves the "chicken-and-egg".
In fact it's going to be a great tracking "fake future upstream" staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide
I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 -> #24) and other little bits like Panda dt I could remove from our tree and use these common versions for.
Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch. In fact, you've made a good point, and I'll probably just stop merging the tracking-unsorted into linux-linaro-core-tracking. This unsorted stuff is mostly "orphaned" commits from very old linaro kernel releases and the "last minute before the release" fixes. In a perfect world this unsorted topic just shouldn't exist.
<snip>
I've removed the tracking-unsorted branch from linux-linaro-core-tracking. This resulted in the following 9 commits being dropped:
CONFIG: Add minimal omap4 defconfig to boot linux-linaro 2bc8501 Perf: Fallback to /bin/more if less is not found for perf pager 01d1982 dt: Linux dt usage model documentation d5b8cf0 arm/dt: Add basic device tree support for mx51 and mx53 boards 448e735 arm/dt: omap3 basic device tree board support 2c61e3e arm/dt: add versatile dtb build rules 19316ff dt: Add id to AUXDATA structure eca594e ARM: kprobes: work around build errors fcf3f96 usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
No other changes, as there were no updates to the topics and to the mainline since yesterday.
Thanks, Andrey
On 04/26/2012 01:54 AM, Somebody in the thread at some point said:
Hi -
I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 -> #24) and other little bits like Panda dt I could remove from our tree and use these common versions for.
Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch.
It's just that one patch from Grant that sets up the DT machine name stuff in board-omap4panda. If it's not intentional you're providing it I can stick it back on when you remove it on your side.
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
No, it wasn't. In the Android patchset all their new config options are "y" by default, regardless of CONFIG_ANDROID even. We (well, John Stultz) have started changing these defaults to "n", and to enabling them in configs/android.conf (the WAKELOCK ones, ANDROID_PARANOID_NETWORK, and NET_ACTIVITY_STATS).
Right that's what's needed. I'll just wait for this to go away as we track -core then.
As I mentioned before the LT trees also have some config mistakes like this that never show up on their tree because the stuff is always configured on. When they're combined, several small - trivial - Kconfig bugs to fix like that will shake out from all over. When we start seeing complaints about that, I'll know we're really getting our teeth into combining trees.
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree,
yes (this comes from the "unsorted" topic wich I am going to drop from this tree) ...
Fine.
but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
...and yes
Although as I say our tracking is still missing some topics compared to tilt-3.3 as we are uplevelling, with this change of basis and elimination of CMA#21 delta we had until now, actually tilt-tracking can be considered for trial merge in unified tree I think. It's not very meaningful in terms of usefulness of our tree right now but it certainly should be interesting in terms of what makes trouble, if anything.
Very good. I was thinking about creating (reusing actually) linux-linaro-tracking branch to be the linux-linaro-core-tracking plus the LT's topics. But I still have quite a long TODO list, and linux-linaro-core-tracking and linux-linaro branches are higher priorities for me. So no commitments WRT linux-linaro-tracking at the moment :)
Well, it's not like I'm in a rush for it. But if we're not piling on more LT trees aimed at 3.4 soon, we probably don't get a meaningful combined tree for 3.4 release. (I don't think ARM LT content + one other LT tree tells us much since great as ARM LT stuff is, it's not a full BSP tree like other LTs but just introduces novel features that have nothing to conflict with except the odd Makefile one-liner).
Generally if all LTs are basing and tracking on -core, 90% of the integration-readiness job is done. So long as there's not too much off-piste content showing up in diffstat from anyone, you'll likely be surprised how easily they go together at that point (plus or minus inevitable "surprise" from each tree that another tree had also patched that Kconfig / Makefile now).
-Andy
On 04/26/2012 10:49 AM, Somebody in the thread at some point said:
On 04/26/2012 01:54 AM, Somebody in the thread at some point said:
Hi -
Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch.
It's just that one patch from Grant that sets up the DT machine name stuff in board-omap4panda. If it's not intentional you're providing it I can stick it back on when you remove it on your side.
This happened and I added the support back in OK, thanks.
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
No, it wasn't. In the Android patchset all their new config options are "y" by default, regardless of CONFIG_ANDROID even. We (well, John Stultz) have started changing these defaults to "n", and to enabling them in configs/android.conf (the WAKELOCK ones, ANDROID_PARANOID_NETWORK, and NET_ACTIVITY_STATS).
Right that's what's needed. I'll just wait for this to go away as we track -core then.
Since it's still there in today's llct and making me see double, I tracked it down to this from Androidization series
109a3af ARM: Make low-level printk work
I don't think that makes any sense any more and should be removed, unless there's some case on Android side that really needs it. Vanilla has better DEBUG_LL support now since 2005 when that patch was introduced and the Android kernels will inherit it. I've reverted it in my tree since we commonly need DEBUG_LL on (but we don't need printascii garbling all our logging as if there was an echo in there).
-Andy
07.05.2012 09:05, Andy Green написал:
On 04/26/2012 10:49 AM, Somebody in the thread at some point said:
On 04/26/2012 01:54 AM, Somebody in the thread at some point said:
Hi -
Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch.
It's just that one patch from Grant that sets up the DT machine name stuff in board-omap4panda. If it's not intentional you're providing it I can stick it back on when you remove it on your side.
This happened and I added the support back in OK, thanks.
Thanks! I'll drop this commit from the tracking-unsorted branch after this long weekend ends (on Thursday). And will move the linux-linaro to v3.4-rc6.
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
No, it wasn't. In the Android patchset all their new config options are "y" by default, regardless of CONFIG_ANDROID even. We (well, John Stultz) have started changing these defaults to "n", and to enabling them in configs/android.conf (the WAKELOCK ones, ANDROID_PARANOID_NETWORK, and NET_ACTIVITY_STATS).
Right that's what's needed. I'll just wait for this to go away as we track -core then.
Since it's still there in today's llct and making me see double, I tracked it down to this from Androidization series
109a3af ARM: Make low-level printk work
Author: Tony Lindgren tony@atomide.com Date: Mon May 9 14:10:26 2005 -0700
I don't think that makes any sense any more and should be removed, unless there's some case on Android side that really needs it. Vanilla has better DEBUG_LL support now since 2005 when that patch was introduced and the Android kernels will inherit it. I've reverted it in my tree since we commonly need DEBUG_LL on (but we don't need printascii garbling all our logging as if there was an echo in there).
Agreed. A really ancient one.
John, Are there any reasons for Android to keep this patch?
Thanks, Andrey
-Andy
On 05/07/2012 02:09 AM, Andrey Konovalov wrote:
07.05.2012 09:05, Andy Green написал:
Since it's still there in today's llct and making me see double, I tracked it down to this from Androidization series
109a3af ARM: Make low-level printk work
Author: Tony Lindgren tony@atomide.com Date: Mon May 9 14:10:26 2005 -0700
I don't think that makes any sense any more and should be removed, unless there's some case on Android side that really needs it. Vanilla has better DEBUG_LL support now since 2005 when that patch was introduced and the Android kernels will inherit it. I've reverted it in my tree since we commonly need DEBUG_LL on (but we don't need printascii garbling all our logging as if there was an echo in there).
Agreed. A really ancient one.
John, Are there any reasons for Android to keep this patch?
I don't have any particular insight on that one. I'll go ahead and revert it in our tree and bring it up with the Android folks when I try to push some of our changes towards them.
thanks -john
On Tue, 2012-04-24 at 23:43 +0400, Andrey Konovalov wrote:
Greetings,
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies).
I was thinking that it would be useful if this core branch also included the Gator code that is currently in the ARM LT topic.
This is code which we want in all Linaro kernels and if LTs pull in the core branch they will automatically get the latest code without having to pull it from elsewhere.
This way, come the monthly release, if there are problems which mean an LT kernel can't come from the linux-linaro branch, and is instead released from the LT's own tree, then that kernel will still contain Gator, (assuming the LT still pull core into there release).
The Gator code itself is a separate driver, so won't cause more than trivial merge problems for people pulling the core branch.
On 04/27/2012 08:06 PM, Jon Medhurst (Tixy) wrote:
On Tue, 2012-04-24 at 23:43 +0400, Andrey Konovalov wrote:
Greetings,
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies).
I was thinking that it would be useful if this core branch also included the Gator code that is currently in the ARM LT topic.
I've added the armlt-gator topic to the linux-linaro-core-tracking tree.
Thanks, Andrey
This is code which we want in all Linaro kernels and if LTs pull in the core branch they will automatically get the latest code without having to pull it from elsewhere.
This way, come the monthly release, if there are problems which mean an LT kernel can't come from the linux-linaro branch, and is instead released from the LT's own tree, then that kernel will still contain Gator, (assuming the LT still pull core into there release).
The Gator code itself is a separate driver, so won't cause more than trivial merge problems for people pulling the core branch.
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi -
The plan is to rebase this tree on the current mainline tip daily.
Now we're basing on it, our tracking progress depends on these "daily" rebases, but it's stuck since Friday. So we're missing -rc5 for 3 days.
-Andy
On 05/03/2012 04:28 AM, Andy Green wrote:
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi -
The plan is to rebase this tree on the current mainline tip daily.
Now we're basing on it, our tracking progress depends on these "daily" rebases, but it's stuck since Friday. So we're missing -rc5 for 3 days.
Sorry for the delay. I've updated the linux-linaro-core-tracking, but it currently misses the linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after resolving the merge conflicts; guess later today.
Thanks, Andrey
On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov andrey.konovalov@linaro.org wrote:
On 05/03/2012 04:28 AM, Andy Green wrote:
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi -
The plan is to rebase this tree on the current mainline tip daily.
Now we're basing on it, our tracking progress depends on these "daily" rebases, but it's stuck since Friday. So we're missing -rc5 for 3 days.
Sorry for the delay. I've updated the linux-linaro-core-tracking, but it currently misses the linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after resolving the merge conflicts; guess later today.
Is the resolution simple enough? Otherwise, feels that the better scalable approach is that the topic owner (e.g. John Stultz for the time being) gets notified and asked to fix the merge conflict on his side. Your daily merge scripts would then pick it up automatically as soon as the merge conflict is resolved.
Sounds right?
On 05/03/2012 07:15 AM, Alexander Sack wrote:
On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov andrey.konovalov@linaro.org wrote:
Sorry for the delay. I've updated the linux-linaro-core-tracking, but it currently misses the linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after resolving the merge conflicts; guess later today.
Is the resolution simple enough? Otherwise, feels that the better scalable approach is that the topic owner (e.g. John Stultz for the time being) gets notified and asked to fix the merge conflict on his side. Your daily merge scripts would then pick it up automatically as soon as the merge conflict is resolved.
So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 and the Android tree, but when I went to updated the tree sort it out, v.3.4-rc5 merged in without any issues. I suspect the collision is with something else in the linaro tree, but haven't yet gotten any feedback as to what that might be.
thanks -john
On 05/03/2012 08:10 PM, John Stultz wrote:
On 05/03/2012 07:15 AM, Alexander Sack wrote:
On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov andrey.konovalov@linaro.org wrote:
Sorry for the delay. I've updated the linux-linaro-core-tracking, but it currently misses the linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after resolving the merge conflicts; guess later today.
Done. The linaro-android-3.4 topic is back into the linux-linaro-core-tracking again.
Is the resolution simple enough?
Yes, simple enough.
Otherwise, feels that the better scalable approach is that the topic owner (e.g. John Stultz for the time being) gets notified and asked to fix the merge conflict on his side. Your daily merge scripts would then pick it up automatically as soon as the merge conflict is resolved.
Yes.
So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 and the Android tree, but when I went to updated the tree sort it out, v.3.4-rc5 merged in without any issues. I suspect the collision is with something else in the linaro tree, but haven't yet gotten any feedback as to what that might be.
I wasn't exact enough. In fact the linux-linaro-core-tracking is mainline tip based, and the conflicting commits turned out to be post-v3.4-rc5. That's why the confusion.
Thanks, Andrey
On 05/03/2012 09:16 AM, Andrey Konovalov wrote:
On 05/03/2012 08:10 PM, John Stultz wrote:
So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 and the Android tree, but when I went to updated the tree sort it out, v.3.4-rc5 merged in without any issues. I suspect the collision is with something else in the linaro tree, but haven't yet gotten any feedback as to what that might be.
I wasn't exact enough. In fact the linux-linaro-core-tracking is mainline tip based, and the conflicting commits turned out to be post-v3.4-rc5. That's why the confusion.
Ok. I'll watch out for it next time I update my tree.
thanks -john
On Thu, May 3, 2012 at 6:10 PM, John Stultz john.stultz@linaro.org wrote:
On 05/03/2012 07:15 AM, Alexander Sack wrote:
On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov andrey.konovalov@linaro.org wrote:
Sorry for the delay.
I've updated the linux-linaro-core-tracking, but it currently misses the linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after resolving the merge conflicts; guess later today.
Is the resolution simple enough? Otherwise, feels that the better scalable approach is that the topic owner (e.g. John Stultz for the time being) gets notified and asked to fix the merge conflict on his side. Your daily merge scripts would then pick it up automatically as soon as the merge conflict is resolved.
So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 and the Android tree, but when I went to updated the tree sort it out, v.3.4-rc5 merged in without any issues. I suspect the collision is with something else in the linaro tree, but haven't yet gotten any feedback as to what that might be.
OK, feels we could benefit from getting Andreys tools out and enable you to easily fold linux-linaro with your your own local topic?
Would this help you to more easily converge, prepare and maintain topics that coexist in linux-linaro?
On 05/03/2012 09:31 AM, Alexander Sack wrote:
On Thu, May 3, 2012 at 6:10 PM, John Stultzjohn.stultz@linaro.org wrote:
On 05/03/2012 07:15 AM, Alexander Sack wrote:
On Thu, May 3, 2012 at 4:00 PM, Andrey Konovalov andrey.konovalov@linaro.org wrote:
Sorry for the delay.
I've updated the linux-linaro-core-tracking, but it currently misses the linaro-android-3.4 topic. Will put the linaro-android-3.4 topic back after resolving the merge conflicts; guess later today.
Is the resolution simple enough? Otherwise, feels that the better scalable approach is that the topic owner (e.g. John Stultz for the time being) gets notified and asked to fix the merge conflict on his side. Your daily merge scripts would then pick it up automatically as soon as the merge conflict is resolved.
So Andrey mailed me that there was a conflict between Linus' v3.4-rc5 and the Android tree, but when I went to updated the tree sort it out, v.3.4-rc5 merged in without any issues. I suspect the collision is with something else in the linaro tree, but haven't yet gotten any feedback as to what that might be.
OK, feels we could benefit from getting Andreys tools out and enable you to easily fold linux-linaro with your your own local topic?
I think in this case we've already cleared it up as a slight communication issue.
Would this help you to more easily converge, prepare and maintain topics that coexist in linux-linaro?
Probably not. I'm unable to dedicate as much time to merging items as Andrey, so I'm not likely able to keep pace. As it stands now, I update the Android tree at least ~once a week (sometimes more). So Andrey notices collisions before I do. Usually he then pings me and that prompts me to try to solve it.
Although I've had a few cases where at Andrey's prodding I spend a few hours resolving the collision and testing the resulting tree, only to find the Android team did the same in parallel. Usually then I just pick up the Android teams' work, but I'm not happy about burning my time that way.
This is one of the drawbacks of being always too close to the edge. We end up trying to address issues that others in the community also are addressing in parallel. I think its great to be proactive this way (especially if you're really the patch-queue owner), but it can keep us busy and we miss out on leveraging others work.
thanks -john
-
Alexander Sack -
Andrey Konovalov -
Andy Green -
John Stultz -
Jon Medhurst (Tixy) -
Ricardo Salveti