From: Olof Johansson <hidden> Date: 2012-05-12 05:29:42
On Fri, May 11, 2012 at 12:01 PM, Rafael J. Wysocki [off-list ref] wrote:
Hi,
Please pull changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3
? ?Linux 3.4-rc6
with top-most commit 5658c94096c16e769203b6dea5e5f04e7ff12633
? ?Merge branch 'renesas-kzm9g' into renesas-soc-new
from the git repository at:
?git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc-new
to receive new Renesas ARM-based platforms material for v3.5. ?Included are:
?* Urgent regression and SMP fixes (also included in the fixes branch that I've
? just sent a separate pull request for in the hope it is still possible to
? push them for v3.4). ?Two of those fixes are duplicated in the renesas-sh7372
? branch, which is because I learned that they were fixes for recent
? regressions after they had gone to that branch. ?Sorry about that.
?* Updates for boards based on the sh7372 and r8a7740 SoCs.
?* Support for 2 new boards, armadillo800eva and KZM-A9-GT.
Hi Rafael,
If you take a look at how the other ARM subarch maintainers organize
the patches that they feed up to us, you'll see that they group them
either per functional topic, or more commonly per subject such as
"core soc updates", "soc driver updates", "board updates", "device
tree updates", "cleanup", and so on.
That fits the model we've been having on arm-soc as well, since we
split our tree up per category like that, and send those cross-section
branches between different vendors (but same categories) up to Linus
that way.
So, would you mind taking a look at what you have in the new-soc
branch and reshuffling things a bit? Looking at the history of the
new-soc branch and the rest of the repo, it seems that you're already
more or less organizing your tree the way I am asking for, it's just
that you merged them all together before sending this pull request.
Thanks!
-Olof
From: Rafael J. Wysocki <hidden> Date: 2012-05-12 19:58:13
On Saturday, May 12, 2012, Olof Johansson wrote:
On Fri, May 11, 2012 at 12:01 PM, Rafael J. Wysocki [off-list ref] wrote:
quoted
Hi,
Please pull changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3
Linux 3.4-rc6
with top-most commit 5658c94096c16e769203b6dea5e5f04e7ff12633
Merge branch 'renesas-kzm9g' into renesas-soc-new
from the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc-new
to receive new Renesas ARM-based platforms material for v3.5. Included are:
* Urgent regression and SMP fixes (also included in the fixes branch that I've
just sent a separate pull request for in the hope it is still possible to
push them for v3.4). Two of those fixes are duplicated in the renesas-sh7372
branch, which is because I learned that they were fixes for recent
regressions after they had gone to that branch. Sorry about that.
* Updates for boards based on the sh7372 and r8a7740 SoCs.
* Support for 2 new boards, armadillo800eva and KZM-A9-GT.
Hi Rafael,
If you take a look at how the other ARM subarch maintainers organize
the patches that they feed up to us, you'll see that they group them
either per functional topic, or more commonly per subject such as
"core soc updates", "soc driver updates", "board updates", "device
tree updates", "cleanup", and so on.
That fits the model we've been having on arm-soc as well, since we
split our tree up per category like that, and send those cross-section
branches between different vendors (but same categories) up to Linus
that way.
So, would you mind taking a look at what you have in the new-soc
branch and reshuffling things a bit? Looking at the history of the
new-soc branch and the rest of the repo, it seems that you're already
more or less organizing your tree the way I am asking for, it's just
that you merged them all together before sending this pull request.
Well.
I'd prefer not to rebase any branches and move commits around if that's
what you're talking about, because I have a rule that my branches are not
rebased, except for the next one.
Now, there are three categories of commits in the soc-new branch,
"core soc updates", "board updates" and "new board support". However,
"board updates" depend on "core soc updates" and go together with them
in two branches, "sh7372" and "r8a7740" (branch names are after SoC names
and each branch contains updates for the given SoC and boards based on it).
I can send a pull request to you separately for each of those branches,
if you prefer, or I can merge them together and send a pull request for
the whole (it actually is a separate branch in my tree, called "soc").
The new board support stuff is just that - commits adding support for
new boards. Those things, however, depend on the "core soc updates" and
"board updates", so they are based on the "soc" branch (honestly, I don't
think they will work without the "core" changes). So, while I could
send separate pull requests for the "armadillo800eva" and "kzm9g" branches,
I don't think that merging them without the changes in the "soc" branch will
do any good.
Thanks,
Rafael
From: Rafael J. Wysocki <hidden> Date: 2012-05-12 20:17:14
On Saturday, May 12, 2012, Rafael J. Wysocki wrote:
On Saturday, May 12, 2012, Olof Johansson wrote:
quoted
On Fri, May 11, 2012 at 12:01 PM, Rafael J. Wysocki [off-list ref] wrote:
quoted
Hi,
Please pull changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3
Linux 3.4-rc6
with top-most commit 5658c94096c16e769203b6dea5e5f04e7ff12633
Merge branch 'renesas-kzm9g' into renesas-soc-new
from the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc-new
to receive new Renesas ARM-based platforms material for v3.5. Included are:
* Urgent regression and SMP fixes (also included in the fixes branch that I've
just sent a separate pull request for in the hope it is still possible to
push them for v3.4). Two of those fixes are duplicated in the renesas-sh7372
branch, which is because I learned that they were fixes for recent
regressions after they had gone to that branch. Sorry about that.
* Updates for boards based on the sh7372 and r8a7740 SoCs.
* Support for 2 new boards, armadillo800eva and KZM-A9-GT.
Hi Rafael,
If you take a look at how the other ARM subarch maintainers organize
the patches that they feed up to us, you'll see that they group them
either per functional topic, or more commonly per subject such as
"core soc updates", "soc driver updates", "board updates", "device
tree updates", "cleanup", and so on.
That fits the model we've been having on arm-soc as well, since we
split our tree up per category like that, and send those cross-section
branches between different vendors (but same categories) up to Linus
that way.
So, would you mind taking a look at what you have in the new-soc
branch and reshuffling things a bit? Looking at the history of the
new-soc branch and the rest of the repo, it seems that you're already
more or less organizing your tree the way I am asking for, it's just
that you merged them all together before sending this pull request.
Well.
I'd prefer not to rebase any branches and move commits around if that's
what you're talking about, because I have a rule that my branches are not
rebased, except for the next one.
I will have to rebase the whole thing anyway because of the changes in
"fixes", so I think I'll just create new branches and send pull requests
again.
Thanks,
Rafael
From: Olof Johansson <hidden> Date: 2012-05-12 23:04:10
Hi,
On Sat, May 12, 2012 at 12:58 PM, Rafael J. Wysocki [off-list ref] wrote:
On Saturday, May 12, 2012, Olof Johansson wrote:
quoted
On Fri, May 11, 2012 at 12:01 PM, Rafael J. Wysocki [off-list ref] wrote:
quoted
Hi,
Please pull changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3
? ?Linux 3.4-rc6
with top-most commit 5658c94096c16e769203b6dea5e5f04e7ff12633
? ?Merge branch 'renesas-kzm9g' into renesas-soc-new
from the git repository at:
?git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc-new
to receive new Renesas ARM-based platforms material for v3.5. ?Included are:
?* Urgent regression and SMP fixes (also included in the fixes branch that I've
? just sent a separate pull request for in the hope it is still possible to
? push them for v3.4). ?Two of those fixes are duplicated in the renesas-sh7372
? branch, which is because I learned that they were fixes for recent
? regressions after they had gone to that branch. ?Sorry about that.
?* Updates for boards based on the sh7372 and r8a7740 SoCs.
?* Support for 2 new boards, armadillo800eva and KZM-A9-GT.
Hi Rafael,
If you take a look at how the other ARM subarch maintainers organize
the patches that they feed up to us, you'll see that they group them
either per functional topic, or more commonly per subject such as
"core soc updates", "soc driver updates", "board updates", "device
tree updates", "cleanup", and so on.
That fits the model we've been having on arm-soc as well, since we
split our tree up per category like that, and send those cross-section
branches between different vendors (but same categories) up to Linus
that way.
So, would you mind taking a look at what you have in the new-soc
branch and reshuffling things a bit? Looking at the history of the
new-soc branch and the rest of the repo, it seems that you're already
more or less organizing your tree the way I am asking for, it's just
that you merged them all together before sending this pull request.
Well.
I'd prefer not to rebase any branches and move commits around if that's
what you're talking about, because I have a rule that my branches are not
rebased, except for the next one.
Yeah, sorry for not giving you a heads up on this before. Hopefully
it's just a bootstrap issue this first merge window that you're
sending things through our tree.
Now, there are three categories of commits in the soc-new branch,
"core soc updates", "board updates" and "new board support". ?However,
"board updates" depend on "core soc updates" and go together with them
in two branches, "sh7372" and "r8a7740" (branch names are after SoC names
and each branch contains updates for the given SoC and boards based on it).
I can send a pull request to you separately for each of those branches,
if you prefer, or I can merge them together and send a pull request for
the whole (it actually is a separate branch in my tree, called "soc").
In general we don't mind seeing each branch separately, and having
dependencies between them is perfectly fine. Other subarch trees do
this all the time. So having the core updates as a prereq (and
included in) the two SoC names is perfectly fine, the dependencies
will carry over to how we merge them into our next/* branches in
arm-soc.
The new board support stuff is just that - commits adding support for
new boards. ?Those things, however, depend on the "core soc updates" and
"board updates", so they are based on the "soc" branch (honestly, I don't
think they will work without the "core" changes). ?So, while I could
send separate pull requests for the "armadillo800eva" and "kzm9g" branches,
I don't think that merging them without the changes in the "soc" branch will
do any good.
Again, that's fine. We have a "waterfall" of dependencies through the
arm-soc next/* branches and this will normally fit right in.
To see how we organize (and document) the branches we have pulled in,
take a look at arch/arm/arm-soc-for-next-contents.txt in the for-next
branch of the arm-soc tree:
http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=blob;f=arch/arm/arm-soc-for-next-contents.txt;h=8ca6bef667fa81c355a0a9200804d20c16173f2d;hb=refs/heads/for-next
In general, the document is sorted such that the prerequisites for
later branches are listed above. In some cases it means that we need
to have more than one topic branch due to otherwise circular or
awkward dependencies, for example next/dt and next/dt2.
General organization and order tends to start out as:
* cleanups
* fixes
* device tree updates
* core soc support (new socs, etc)
* soc drivers and soc-related items. This time we split them up a bit
(pm, pinctrl, clock, drivers)
* boards (generally very limited new board introductions, mostly updates)
But over time order can be somewhat reshuffled due to added dependencies.
The for-next and next/* branches are not guaranteed to be stable,
since we have in the past had to drop branches and rebuild them. In
general, downstream developers should be basing their work on the
specific subarch trees and not on arm-soc. There are a few exceptions
for tree-wide cleanups but even then, basing it on regular mainline
makes much more sense.
-Olof