Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git%3Ba=summary
git://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Nicolas
On 10/11/2011 11:13 AM, Somebody in the thread at some point said:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git;a=summary git://git.linaro.org/kernel/linux-linaro-3.1.gitThis is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Great... I'll plug this together with my tracking and make a first try at tilt-linux-linaro-3.1.
-Andy
On Tue, 2011-10-11 at 11:17 +0800, Andy Green wrote:
On 10/11/2011 11:13 AM, Somebody in the thread at some point said:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git;a=summary git://git.linaro.org/kernel/linux-linaro-3.1.gitThis is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Great... I'll plug this together with my tracking and make a first try at tilt-linux-linaro-3.1.
Cool. In the absence of a official Android 3.1 common tree, I sat down today and actually did the same with the TI omapzoom p-common tree (just adding the linaro+android defconfigs and base origen support).
There were a few usb related mis-merges in that tree that wouldn't compile, so I fixed up. I'm guessing you've already hit and fixed them as well, but if not, you can just grab it, its here:
git://git.linaro.org/people/jstultz/android.git linaro-android-3.1-fport
There's only one new change in Nico's tree that I didn't get to test earlier today, but earlier I got it booting on both pandas, beagle, and origen.
thanks -john
On 10/11/2011 11:43 AM, Somebody in the thread at some point said:
On Tue, 2011-10-11 at 11:17 +0800, Andy Green wrote:
On 10/11/2011 11:13 AM, Somebody in the thread at some point said:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git;a=summary git://git.linaro.org/kernel/linux-linaro-3.1.gitThis is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Great... I'll plug this together with my tracking and make a first try at tilt-linux-linaro-3.1.
Cool. In the absence of a official Android 3.1 common tree, I sat down today and actually did the same with the TI omapzoom p-common tree (just adding the linaro+android defconfigs and base origen support).
Is there any reason not to base off my version of it? There's no guarantee TI's tree will go on for any longer than they have a use for it whereas I am planning to do this for a whole cycle.
There were a few usb related mis-merges in that tree that wouldn't compile, so I fixed up. I'm guessing you've already hit and fixed them as well, but if not, you can just grab it, its here:
My tree has worked for a while.
git://git.linaro.org/people/jstultz/android.git linaro-android-3.1-fport
There's only one new change in Nico's tree that I didn't get to test earlier today, but earlier I got it booting on both pandas, beagle, and origen.
That is good.
While we're talking, I noticed cpufreq topic on the re-ordered tree looks like it's a selfcontained little history for a new governor called 'interactive'. Do you know anything about the history of efforts to get this upstream?
-Andy
On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
On 10/11/2011 11:43 AM, Somebody in the thread at some point said:
Cool. In the absence of a official Android 3.1 common tree, I sat down today and actually did the same with the TI omapzoom p-common tree (just adding the linaro+android defconfigs and base origen support).
Is there any reason not to base off my version of it? There's no guarantee TI's tree will go on for any longer than they have a use for it whereas I am planning to do this for a whole cycle.
No specific reason not to, just that from reading your announcement from last week, I thought the p-android-3.1 branch was just the rebased android common tree, and it wasn't clear if the tilt tree had other things in it or not.
There were a few usb related mis-merges in that tree that wouldn't compile, so I fixed up. I'm guessing you've already hit and fixed them as well, but if not, you can just grab it, its here:
My tree has worked for a while.
git://git.linaro.org/people/jstultz/android.git linaro-android-3.1-fport
There's only one new change in Nico's tree that I didn't get to test earlier today, but earlier I got it booting on both pandas, beagle, and origen.
That is good.
While we're talking, I noticed cpufreq topic on the re-ordered tree looks like it's a selfcontained little history for a new governor called 'interactive'. Do you know anything about the history of efforts to get this upstream?
So its never been submitted that I'm aware of. I've chatted with some non-android google folks who do more upstream cpufreq work, and they weren't really aware of it.
It was on my list for the trivial-tree earlier, but I never got to it (I still need to get the smaller cgroup patches sent out). If you think its more interesting, I can bump its priority and try to get it out for discussion. I have neglected the trivial tree work this cycle, so it would probably be good to get another item or two our for discussion.
thanks -john
On Tue, Oct 11, 2011 at 12:13 PM, john stultz johnstul@us.ibm.com wrote:
On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
While we're talking, I noticed cpufreq topic on the re-ordered tree looks like it's a selfcontained little history for a new governor called 'interactive'. Do you know anything about the history of efforts to get this upstream?
So its never been submitted that I'm aware of. I've chatted with some non-android google folks who do more upstream cpufreq work, and they weren't really aware of it.
It was on my list for the trivial-tree earlier, but I never got to it (I still need to get the smaller cgroup patches sent out). If you think its more interesting, I can bump its priority and try to get it out for discussion. I have neglected the trivial tree work this cycle, so it would probably be good to get another item or two our for discussion.
Based on conversations I've had with several vendors working on Android, interactive governor was written by the folks at Google to deal with some performance problems of ondemand.
Since then, ondemand has seen several fixes to its performance problems and most folks I've talked to think that the problems are solved. Is interactive governor still being enabled by default on Android devices?
/Amit
On 10/11/2011 03:04 PM, Somebody in the thread at some point said:
On Tue, Oct 11, 2011 at 12:13 PM, john stultzjohnstul@us.ibm.com wrote:
On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
While we're talking, I noticed cpufreq topic on the re-ordered tree looks like it's a selfcontained little history for a new governor called 'interactive'. Do you know anything about the history of efforts to get this upstream?
So its never been submitted that I'm aware of. I've chatted with some non-android google folks who do more upstream cpufreq work, and they weren't really aware of it.
It was on my list for the trivial-tree earlier, but I never got to it (I still need to get the smaller cgroup patches sent out). If you think its more interesting, I can bump its priority and try to get it out for discussion. I have neglected the trivial tree work this cycle, so it would probably be good to get another item or two our for discussion.
Based on conversations I've had with several vendors working on Android, interactive governor was written by the folks at Google to deal with some performance problems of ondemand.
Since then, ondemand has seen several fixes to its performance problems and most folks I've talked to think that the problems are solved. Is interactive governor still being enabled by default on Android devices?
Thanks for the background.
It's not enabled on our tilt-android-tracking at the minute because having working CPUFREQ is such a novelty we forgot to enable it.
I'll set it to ondemand by default then and enable interactive so we can see if makes any odds.
-Andy
On 10/11/2011 02:43 PM, Somebody in the thread at some point said:
On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
On 10/11/2011 11:43 AM, Somebody in the thread at some point said:
Cool. In the absence of a official Android 3.1 common tree, I sat down today and actually did the same with the TI omapzoom p-common tree (just adding the linaro+android defconfigs and base origen support).
Is there any reason not to base off my version of it? There's no guarantee TI's tree will go on for any longer than they have a use for it whereas I am planning to do this for a whole cycle.
No specific reason not to, just that from reading your announcement from last week, I thought the p-android-3.1 branch was just the rebased android common tree, and it wasn't clear if the tilt tree had other things in it or not.
What Jassi did was take the TI tree and compare it against the common-3.0 we last had. He found some missing patches about gadget IIRC and brought them over additionally.
linaro-androidization-tracking doesn't have anything else on it at all except vanilla + stuff from TI and common-3.0 filling in the gaps.
There were a few usb related mis-merges in that tree that wouldn't compile, so I fixed up. I'm guessing you've already hit and fixed them as well, but if not, you can just grab it, its here:
I think what I'll do is study the diff between the two trees with an aim to reducing that to nothing hopefully by moving things around slightly on my side.
It won't help anyone to have different versions of "common-3.1" floating about, especially if you think about after 3.1 release your new one will branch off and become release-based and mine will continue into the mysteries of -rc0, if we get Android bugs coming on one but not the other it won't help if there's some lingering question about how they may have differed to start with.
While we're talking, I noticed cpufreq topic on the re-ordered tree looks like it's a selfcontained little history for a new governor called 'interactive'. Do you know anything about the history of efforts to get this upstream?
So its never been submitted that I'm aware of. I've chatted with some non-android google folks who do more upstream cpufreq work, and they weren't really aware of it.
It was on my list for the trivial-tree earlier, but I never got to it (I still need to get the smaller cgroup patches sent out). If you think its
It sounds like I should have put cgroup on its own topic as well.
more interesting, I can bump its priority and try to get it out for discussion. I have neglected the trivial tree work this cycle, so it would probably be good to get another item or two our for discussion.
Amit wrote more about cpufreq so I replied there.
Thinking about what's in the topics it seems there are quite a few opportunities for patch folding / consolidation / optimization, ignoring upstreaming. A few times in one topic a patch is introduced and then reverted, or the patch is introduced and a little later there is a cleanup patch. It should be at least arguable to fold these, trying to keep track of who did what in the commit log. (Good example is ion topic, there are 12 "history" patches that could be folded into the first one).
It complicates the question if this tree 'has' xyz patch, but it simplifies the patchset. I think 467 patches was enough for this it might be good if it shrank considerably rather than keep on acquiring its own history.
-Andy
On Tue, 2011-10-11 at 16:08 +0800, Andy Green wrote:
On 10/11/2011 02:43 PM, Somebody in the thread at some point said:
On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
On 10/11/2011 11:43 AM, Somebody in the thread at some point said:
Cool. In the absence of a official Android 3.1 common tree, I sat down today and actually did the same with the TI omapzoom p-common tree (just adding the linaro+android defconfigs and base origen support).
Is there any reason not to base off my version of it? There's no guarantee TI's tree will go on for any longer than they have a use for it whereas I am planning to do this for a whole cycle.
No specific reason not to, just that from reading your announcement from last week, I thought the p-android-3.1 branch was just the rebased android common tree, and it wasn't clear if the tilt tree had other things in it or not.
What Jassi did was take the TI tree and compare it against the common-3.0 we last had. He found some missing patches about gadget IIRC and brought them over additionally.
linaro-androidization-tracking doesn't have anything else on it at all except vanilla + stuff from TI and common-3.0 filling in the gaps.
There were a few usb related mis-merges in that tree that wouldn't compile, so I fixed up. I'm guessing you've already hit and fixed them as well, but if not, you can just grab it, its here:
I think what I'll do is study the diff between the two trees with an aim to reducing that to nothing hopefully by moving things around slightly on my side.
It won't help anyone to have different versions of "common-3.1" floating about, especially if you think about after 3.1 release your new one will branch off and become release-based and mine will continue into the mysteries of -rc0, if we get Android bugs coming on one but not the other it won't help if there's some lingering question about how they may have differed to start with.
Sounds like a reasonable plan. Although, given that we both started with the same omapzoom branch (or am I mistaken with that?), I suspect we're likely to be pretty close already.
[snip]
Thinking about what's in the topics it seems there are quite a few opportunities for patch folding / consolidation / optimization, ignoring upstreaming. A few times in one topic a patch is introduced and then reverted, or the patch is introduced and a little later there is a cleanup patch. It should be at least arguable to fold these, trying to keep track of who did what in the commit log. (Good example is ion topic, there are 12 "history" patches that could be folded into the first one).
It complicates the question if this tree 'has' xyz patch, but it simplifies the patchset. I think 467 patches was enough for this it might be good if it shrank considerably rather than keep on acquiring its own history.
Indeed, it would be very nice if the patch set was condensed. Google Android devs have admitted the tree could use a heavy cleanup, but so far it seems they won't invest in doing so.
I'd hesitate to recommend folding the patch set yourself, unless the fixes being folded in are *extremely* trivial. As a general rule, with patches that are the works of others, its usually best to check with the patch authors before folding. Otherwise you diminish the history of the work, and possibly reduce the credit deserved to those who submit fixes.
Although, I admit that its unlikely such folded patches would get pushed directly upstream, reducing the concern that the rewritten history of the work would end up fixed in stone upstream. But it still feels a bit like a fork-of-a-fork to me, and doesn't help with Linaro goals of staying close to upstream (whomever upstream is).
Additionally, I worry that with a heavily reordered and folded patch queue, it might be difficult whenever android.git.kernel.org returns, to sync up with updated Google trees. But I'll leave the weighing of that trade-off with the benefit of handling fewer patches to you.
All that said, I think in future talks with Google devs, we should see if there is not some way for us to help them clean up the patch set. Possibly just by pointing them to your topic-ized tree to see if they could start with that for their next cycle, and hopefully do the more obvious folding themselves.
thanks -john
On 10/12/2011 05:44 AM, Somebody in the thread at some point said:
On Tue, 2011-10-11 at 16:08 +0800, Andy Green wrote:
On 10/11/2011 02:43 PM, Somebody in the thread at some point said:
On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
On 10/11/2011 11:43 AM, Somebody in the thread at some point said:
Cool. In the absence of a official Android 3.1 common tree, I sat down today and actually did the same with the TI omapzoom p-common tree (just adding the linaro+android defconfigs and base origen support).
Is there any reason not to base off my version of it? There's no guarantee TI's tree will go on for any longer than they have a use for it whereas I am planning to do this for a whole cycle.
No specific reason not to, just that from reading your announcement from last week, I thought the p-android-3.1 branch was just the rebased android common tree, and it wasn't clear if the tilt tree had other things in it or not.
What Jassi did was take the TI tree and compare it against the common-3.0 we last had. He found some missing patches about gadget IIRC and brought them over additionally.
linaro-androidization-tracking doesn't have anything else on it at all except vanilla + stuff from TI and common-3.0 filling in the gaps.
There were a few usb related mis-merges in that tree that wouldn't compile, so I fixed up. I'm guessing you've already hit and fixed them as well, but if not, you can just grab it, its here:
I think what I'll do is study the diff between the two trees with an aim to reducing that to nothing hopefully by moving things around slightly on my side.
It won't help anyone to have different versions of "common-3.1" floating about, especially if you think about after 3.1 release your new one will branch off and become release-based and mine will continue into the mysteries of -rc0, if we get Android bugs coming on one but not the other it won't help if there's some lingering question about how they may have differed to start with.
Sounds like a reasonable plan. Although, given that we both started with the same omapzoom branch (or am I mistaken with that?), I suspect we're likely to be pretty close already.
I don't know your basis yet, I'll be doing the zero-diff thing today. But it would have been easier if we had cooperated on the same tree directly. Zeroing the diff will mean the outcome is the same just you redid our initial work, and I have to do additional work to hide the difference in the result. It doesn't feel like we found the smartest approach to work together this time.
[snip]
Thinking about what's in the topics it seems there are quite a few opportunities for patch folding / consolidation / optimization, ignoring upstreaming. A few times in one topic a patch is introduced and then reverted, or the patch is introduced and a little later there is a cleanup patch. It should be at least arguable to fold these, trying to keep track of who did what in the commit log. (Good example is ion topic, there are 12 "history" patches that could be folded into the first one).
It complicates the question if this tree 'has' xyz patch, but it simplifies the patchset. I think 467 patches was enough for this it might be good if it shrank considerably rather than keep on acquiring its own history.
Indeed, it would be very nice if the patch set was condensed. Google Android devs have admitted the tree could use a heavy cleanup, but so far it seems they won't invest in doing so.
Do you know who was saying that inside Google?
I'd hesitate to recommend folding the patch set yourself, unless the fixes being folded in are *extremely* trivial. As a general rule, with patches that are the works of others, its usually best to check with the patch authors before folding. Otherwise you diminish the history of the work, and possibly reduce the credit deserved to those who submit fixes.
I don't think we need to worry about attribution, already in the patchset the authors took the approach to bring in the changelog from the folded patchsets into the resulting one. We can just follow that scheme.
Although, I admit that its unlikely such folded patches would get pushed directly upstream, reducing the concern that the rewritten history of the work would end up fixed in stone upstream. But it still feels a bit
As I say Google already seem to have had a go and found attribution merging rather than loss acceptable.
like a fork-of-a-fork to me, and doesn't help with Linaro goals of staying close to upstream (whomever upstream is).
The tree, the files, the diff, though will be the same as before after this kind of patch folding, it will be no closer or further away from its currently hidden upstream. When people talk about 'fork' and 'close to upstream' they usually mean actual changes to the tree.
Additionally, I worry that with a heavily reordered and folded patch queue, it might be difficult whenever android.git.kernel.org returns, to sync up with updated Google trees. But I'll leave the weighing of that trade-off with the benefit of handling fewer patches to you.
There's a flow based around git diff and git blame that will allow detection of new patches and integration of changes on top of the same starting point, even if one side has the starting point as raw files with no patch history. I expect that can be automated like the rest of the management I am doing is largely automated now.
If the reorder had caused lots of damage topic by topic that would be a bad problem, but actually it broke apart surprisingly smoothly. Most of the topics have very little or no dependencies outside their little world.
The worst that can happen is Google ignore us and we have to restart tracking with common-3.2 assuming that's available. But reviewing all 470 patches briefly as I did to reorder them, I expect we find 90% of these patches the same in common-3.2 and it's just the additional patches I need to integrate into the topic-based reorder. In the meanwhile, until common-3.2 is coming, I get the advantage of the re-order for tracking uplevelling.
All that said, I think in future talks with Google devs, we should see if there is not some way for us to help them clean up the patch set. Possibly just by pointing them to your topic-ized tree to see if they could start with that for their next cycle, and hopefully do the more obvious folding themselves.
I don't seem to have reached the attention of the common- guys at Google yet. I agree it would be best to clean the thing in cooperation with Google guys so we can pre-clear the approach for each topic.
-Andy
On Wed, 2011-10-12 at 08:40 +0800, Andy Green wrote:
On 10/12/2011 05:44 AM, Somebody in the thread at some point said:
On Tue, 2011-10-11 at 16:08 +0800, Andy Green wrote:
On 10/11/2011 02:43 PM, Somebody in the thread at some point said:
On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
On 10/11/2011 11:43 AM, Somebody in the thread at some point said:
Cool. In the absence of a official Android 3.1 common tree, I sat down today and actually did the same with the TI omapzoom p-common tree (just adding the linaro+android defconfigs and base origen support).
Is there any reason not to base off my version of it? There's no guarantee TI's tree will go on for any longer than they have a use for it whereas I am planning to do this for a whole cycle.
No specific reason not to, just that from reading your announcement from last week, I thought the p-android-3.1 branch was just the rebased android common tree, and it wasn't clear if the tilt tree had other things in it or not.
What Jassi did was take the TI tree and compare it against the common-3.0 we last had. He found some missing patches about gadget IIRC and brought them over additionally.
linaro-androidization-tracking doesn't have anything else on it at all except vanilla + stuff from TI and common-3.0 filling in the gaps.
There were a few usb related mis-merges in that tree that wouldn't compile, so I fixed up. I'm guessing you've already hit and fixed them as well, but if not, you can just grab it, its here:
I think what I'll do is study the diff between the two trees with an aim to reducing that to nothing hopefully by moving things around slightly on my side.
It won't help anyone to have different versions of "common-3.1" floating about, especially if you think about after 3.1 release your new one will branch off and become release-based and mine will continue into the mysteries of -rc0, if we get Android bugs coming on one but not the other it won't help if there's some lingering question about how they may have differed to start with.
Sounds like a reasonable plan. Although, given that we both started with the same omapzoom branch (or am I mistaken with that?), I suspect we're likely to be pretty close already.
I don't know your basis yet, I'll be doing the zero-diff thing today.
I took a quick look and it seemed like mostly bits from 3.1-rc code. But I could have missed some items.
But it would have been easier if we had cooperated on the same tree directly. Zeroing the diff will mean the outcome is the same just you redid our initial work, and I have to do additional work to hide the difference in the result. It doesn't feel like we found the smartest approach to work together this time.
I really didn't do much work at all. Only merging, minor fixes, and testing. I can also rebase onto your tree if you think its a big issue. It just sounded from above that you wanted to adjust things in your tree. I apologize for my confusion.
[snip]
Thinking about what's in the topics it seems there are quite a few opportunities for patch folding / consolidation / optimization, ignoring upstreaming. A few times in one topic a patch is introduced and then reverted, or the patch is introduced and a little later there is a cleanup patch. It should be at least arguable to fold these, trying to keep track of who did what in the commit log. (Good example is ion topic, there are 12 "history" patches that could be folded into the first one).
It complicates the question if this tree 'has' xyz patch, but it simplifies the patchset. I think 467 patches was enough for this it might be good if it shrank considerably rather than keep on acquiring its own history.
Indeed, it would be very nice if the patch set was condensed. Google Android devs have admitted the tree could use a heavy cleanup, but so far it seems they won't invest in doing so.
Do you know who was saying that inside Google?
I think it was Dima? I had asked if they would consider doing topic branches (very similar to what your doing) so picking things out for upstreaming would be easier. He said it sounded interesting, but if they would go through to break things out, they would also want to clean things up (ie: folding) and that's just work they haven't ever had time for.
My impression was that their attention was very much elsewhere from the kernel/common tree, and that they saw it as a bunch of needed legacy stuff they have to carry along with as little effort as possible.
I'd hesitate to recommend folding the patch set yourself, unless the fixes being folded in are *extremely* trivial. As a general rule, with patches that are the works of others, its usually best to check with the patch authors before folding. Otherwise you diminish the history of the work, and possibly reduce the credit deserved to those who submit fixes.
I don't think we need to worry about attribution, already in the patchset the authors took the approach to bring in the changelog from the folded patchsets into the resulting one. We can just follow that scheme.
Just voicing my concern.
[snip]
All that said, I think in future talks with Google devs, we should see if there is not some way for us to help them clean up the patch set. Possibly just by pointing them to your topic-ized tree to see if they could start with that for their next cycle, and hopefully do the more obvious folding themselves.
I don't seem to have reached the attention of the common- guys at Google yet. I agree it would be best to clean the thing in cooperation with Google guys so we can pre-clear the approach for each topic.
I can sympathize with the difficulty of getting the attention of Google developers. :)
thanks -john
On 10/11/2011 11:17 AM, Somebody in the thread at some point said:
On 10/11/2011 11:13 AM, Somebody in the thread at some point said:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git%3Ba=summary
git://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Great... I'll plug this together with my tracking and make a first try at tilt-linux-linaro-3.1.
I did it and pushed it here
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=shortlog...
but it has a curious regression vs tilt-tracking, if you have a serial console on the commandline, eg on mine normally it says
console=ttyO2,115200n8r
then whether you have CONFIG_DEBUG_LL and EARLYPRINTK or not the boot dies after showing
[ 4.374420] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 4.477783] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0 [ 4.516510] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1 [ 4.539947] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2
ie, at the point where it switches to a proper serial console.
I removed the console=tty02... from the kernel commandline and boot proceeded normally, everything seems to be working.
-Andy
On 10/11/2011 01:45 PM, Somebody in the thread at some point said:
On 10/11/2011 11:17 AM, Somebody in the thread at some point said:
On 10/11/2011 11:13 AM, Somebody in the thread at some point said:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git%3Ba=summary
git://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Great... I'll plug this together with my tracking and make a first try at tilt-linux-linaro-3.1.
I did it and pushed it here
http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git%3Ba=shortlog...
but it has a curious regression vs tilt-tracking, if you have a serial console on the commandline, eg on mine normally it says
console=ttyO2,115200n8r
then whether you have CONFIG_DEBUG_LL and EARLYPRINTK or not the boot dies after showing
Jassi couldn't reproduce this problem, I tried removing the "r" (rts - cts needed for my bluetooth serial adapter I am not actually using at the moment) and all is well. So I guess code changed somewhere to respect (my broken) handshaking.
Now it seems to work fine.
-Andy
Looping other LTs into this discussion. Can we get some input from ST-E, Samsung, and Freescale LTs on what kernel you are working against? Looking at past branches and releases, we tend to get lots of input from Andy and the TI team every month but I'm a bit at a loss as to whether a) everything just works perfectly for the other platforms or b) the other teams are not using Nicolas' kernel.
Thanks, ~Deepak
On 10 October 2011 20:13, Nicolas Pitre nicolas.pitre@linaro.org wrote:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git%3Ba=summary
git://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Nicolas
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On Wed, Oct 12, 2011 at 5:48 AM, Deepak Saxena dsaxena@linaro.org wrote:
Looping other LTs into this discussion. Can we get some input from ST-E, Samsung, and Freescale LTs on what kernel you are working against? Looking at past branches and releases, we tend to get lots of input from Andy and the TI team every month but I'm a bit at a loss as to whether a) everything just works perfectly for the other platforms or b) the other teams are not using Nicolas' kernel.
Hi Deepak,
The freescale LT is working on a v3.1 kernel, and we started with an early v3.1-rc3. Nico's tree is exactly what we are waiting for. We'll do a quick rebase and give more feedback a bit later.
BTW - suppose 3.1 being officially announced very soon, what's the target for this month's release, 3.1 or 3.0?
Thanks, ~Deepak
On 10 October 2011 20:13, Nicolas Pitre nicolas.pitre@linaro.org wrote:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git%3Ba=summary
git://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Nicolas
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On 11/10/11 22:48, Deepak Saxena wrote:
Looping other LTs into this discussion. Can we get some input from ST-E, Samsung, and Freescale LTs on what kernel you are working against? Looking at past branches and releases, we tend to get lots of input from Andy and the TI team every month but I'm a bit at a loss as to whether a) everything just works perfectly for the other platforms or b) the other teams are not using Nicolas' kernel.
The latter. We're not using Nicolas' kernel.
On 10 October 2011 20:13, Nicolas Pitre nicolas.pitre@linaro.org wrote:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git%3Ba=summary
git://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Nicolas
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
Hi Deepak,
On Tue, Oct 11, 2011 at 3:48 PM, Deepak Saxena dsaxena@linaro.org wrote:
Looping other LTs into this discussion. Can we get some input from ST-E, Samsung, and Freescale LTs on what kernel you are working against? Looking at past branches and releases, we tend to get lots of input from Andy and the TI team every month but I'm a bit at a loss as to whether a) everything just works perfectly for the other platforms or b) the other teams are not using Nicolas' kernel.
We're using Nicolas' tree as a base for our Ubuntu and our Android kernel. Our 3.1 patches should be available soon.
Thanks Angus
Thanks, ~Deepak
On 10 October 2011 20:13, Nicolas Pitre nicolas.pitre@linaro.org wrote:
Just a note to let you know that the linux-linaro-3.1 branch is now set up and reachable from those URLS:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.1.git%3Ba=summary
git://git.linaro.org/kernel/linux-linaro-3.1.git
This is currently not exactly v3.1 based as the real v3.1 isn't out yet, however it should be really close. And the only addition I've forward-ported from the linux-linaro-3.0 branch is the EHCI performance fix from Ming Lei given that mainline doesn't appear to address this issue yet.
I'll maintain both linux-linaro-3.0 and linux-linaro-3.1 for a while as I'm not sure what kernel base the consumers of the Linaro kernel are going to settle on for their 11.10 release.
Nicolas
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On 11/10/11 22:48, Deepak Saxena wrote:
Looping other LTs into this discussion. Can we get some input from ST-E, Samsung, and Freescale LTs on what kernel you are working against? Looking at past branches and releases, we tend to get lots of input from Andy and the TI team every month but I'm a bit at a loss as to whether a) everything just works perfectly for the other platforms or b) the other teams are not using Nicolas' kernel.
I guess I was a little rash in my previous email.
We're using Linaro 3.0 as a base for our kernels.
We've not touched it since.
Kind regards, Lee
linaro-kernel@lists.linaro.org
-
Amit Kucheria -
Andy Green -
Angus Ainslie -
Deepak Saxena -
Eric Miao -
john stultz -
Lee Jones -
Nicolas Pitre