From: Russell King - ARM Linux <hidden> Date: 2012-03-12 23:10:16
Marc, Pawel,
Your changes are conflicting badly. Seriously badly. So badly that I'm
not bothering to fix the conflicts because I can't work out what the fix
should be.
You both work for the same frigging organization and yet you seem to
work completely independently (I really don't care if you work in
different departments - the fact of the matter is you're touching the
same code in completely different ways with zero coordination between
yourselves. That's simply broken workflow.)
For example, Marc's deleting arch/arm/plat-versatile/localtimer.c, but
Pawel is modifying it to add DT support for Versatile Express. The
correct solution? Hell knows. And I don't want a solution to the merge
conflict. I want the merge conflict to go away (because I'm not frigging
around applying the same git-rerere immune fixes to a tree I'm regenerating
each night for the kernel autobuilder.)
I'm getting conflicts in arch/arm/mach-vexpress/ct-ca9x4.c and
arch/arm/mach-ux500/timer.c as well, which I'm not going to bother trying
to sort out - the obvious solution for ux500/timer.c doesn't look right.
I've a mind to drop the localtimer changes on the floor until after this
merge window, but unfortunately they're part of devel-stable so I can't.
How do we fix this?
(In the mean time, I've had to reset the kernel autobuilder back to last
nights tree, which is -rc6 based.)
diff --cc arch/arm/mach-ux500/timer.c
index cadf982,fd00024..0000000
From: Russell King - ARM Linux <hidden> Date: 2012-03-12 23:59:51
On Mon, Mar 12, 2012 at 11:10:16PM +0000, Russell King - ARM Linux wrote:
Marc, Pawel,
Your changes are conflicting badly. Seriously badly. So badly that I'm
not bothering to fix the conflicts because I can't work out what the fix
should be.
You both work for the same frigging organization and yet you seem to
work completely independently (I really don't care if you work in
different departments - the fact of the matter is you're touching the
same code in completely different ways with zero coordination between
yourselves. That's simply broken workflow.)
For example, Marc's deleting arch/arm/plat-versatile/localtimer.c, but
Pawel is modifying it to add DT support for Versatile Express. The
correct solution? Hell knows. And I don't want a solution to the merge
conflict. I want the merge conflict to go away (because I'm not frigging
around applying the same git-rerere immune fixes to a tree I'm regenerating
each night for the kernel autobuilder.)
I'm getting conflicts in arch/arm/mach-vexpress/ct-ca9x4.c and
arch/arm/mach-ux500/timer.c as well, which I'm not going to bother trying
to sort out - the obvious solution for ux500/timer.c doesn't look right.
I've a mind to drop the localtimer changes on the floor until after this
merge window, but unfortunately they're part of devel-stable so I can't.
Correction: I haven't been pushing out my devel-stable branch for
apparantly two months (according to gitweb, and no one noticed?), so I
_could_ drop the merge of Marc's tree until the conflicts can be sanely
resolved.
quoted hunk
How do we fix this?
(In the mean time, I've had to reset the kernel autobuilder back to last
nights tree, which is -rc6 based.)
diff --cc arch/arm/mach-ux500/timer.c
index cadf982,fd00024..0000000
From: Olof Johansson <hidden> Date: 2012-03-13 01:23:53
Hi,
On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
[off-list ref] wrote:
On Mon, Mar 12, 2012 at 11:10:16PM +0000, Russell King - ARM Linux wrote:
quoted
Marc, Pawel,
Your changes are conflicting badly. ?Seriously badly. ?So badly that I'm
not bothering to fix the conflicts because I can't work out what the fix
should be.
You both work for the same frigging organization and yet you seem to
work completely independently (I really don't care if you work in
different departments - the fact of the matter is you're touching the
same code in completely different ways with zero coordination between
yourselves. ?That's simply broken workflow.)
For example, Marc's deleting arch/arm/plat-versatile/localtimer.c, but
Pawel is modifying it to add DT support for Versatile Express. ?The
correct solution? ?Hell knows. ?And I don't want a solution to the merge
conflict. ?I want the merge conflict to go away (because I'm not frigging
around applying the same git-rerere immune fixes to a tree I'm regenerating
each night for the kernel autobuilder.)
I'm getting conflicts in arch/arm/mach-vexpress/ct-ca9x4.c and
arch/arm/mach-ux500/timer.c as well, which I'm not going to bother trying
to sort out - the obvious solution for ux500/timer.c doesn't look right.
I've a mind to drop the localtimer changes on the floor until after this
merge window, but unfortunately they're part of devel-stable so I can't.
Correction: I haven't been pushing out my devel-stable branch for
apparantly two months (according to gitweb, and no one noticed?), so I
_could_ drop the merge of Marc's tree until the conflicts can be sanely
resolved.
I haven't noticed because I stopped tracking your tree directly when
you were having server load issues; I tend to have kept an eye on
linux-next-level breakage instead, but probably not as close as I
should have.
Dropping Marc's branch and having him either resubmit on top of
arm-soc like the io cleanup was done, or pull it in as an early
dependency for 3.5 and stage it in an for-armsoc branch sounds like
two good options to me, with no real preference in either direction.
-Olof
From: Marc Zyngier <hidden> Date: 2012-03-13 09:39:57
On 13/03/12 01:23, Olof Johansson wrote:
Hi,
On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
On Mon, Mar 12, 2012 at 11:10:16PM +0000, Russell King - ARM Linux wrote:
quoted
Marc, Pawel,
Your changes are conflicting badly. Seriously badly. So badly that I'm
not bothering to fix the conflicts because I can't work out what the fix
should be.
You both work for the same frigging organization and yet you seem to
work completely independently (I really don't care if you work in
different departments - the fact of the matter is you're touching the
same code in completely different ways with zero coordination between
yourselves. That's simply broken workflow.)
For example, Marc's deleting arch/arm/plat-versatile/localtimer.c, but
Pawel is modifying it to add DT support for Versatile Express. The
correct solution? Hell knows. And I don't want a solution to the merge
conflict. I want the merge conflict to go away (because I'm not frigging
around applying the same git-rerere immune fixes to a tree I'm regenerating
each night for the kernel autobuilder.)
I'm getting conflicts in arch/arm/mach-vexpress/ct-ca9x4.c and
arch/arm/mach-ux500/timer.c as well, which I'm not going to bother trying
to sort out - the obvious solution for ux500/timer.c doesn't look right.
I've a mind to drop the localtimer changes on the floor until after this
merge window, but unfortunately they're part of devel-stable so I can't.
Correction: I haven't been pushing out my devel-stable branch for
apparantly two months (according to gitweb, and no one noticed?), so I
_could_ drop the merge of Marc's tree until the conflicts can be sanely
resolved.
I haven't noticed because I stopped tracking your tree directly when
you were having server load issues; I tend to have kept an eye on
linux-next-level breakage instead, but probably not as close as I
should have.
Dropping Marc's branch and having him either resubmit on top of
arm-soc like the io cleanup was done, or pull it in as an early
dependency for 3.5 and stage it in an for-armsoc branch sounds like
two good options to me, with no real preference in either direction.
I'm happy to rebase my patches on anything that will make the merge
easier (IOW conflict-less).
Russell, would you prefer this series to go via armsoc? This seems the
cleanest solution for the time being.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Russell King - ARM Linux <hidden> Date: 2012-03-13 10:15:25
On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
On 13/03/12 01:23, Olof Johansson wrote:
quoted
Hi,
On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
On Mon, Mar 12, 2012 at 11:10:16PM +0000, Russell King - ARM Linux wrote:
quoted
Marc, Pawel,
Your changes are conflicting badly. Seriously badly. So badly that I'm
not bothering to fix the conflicts because I can't work out what the fix
should be.
You both work for the same frigging organization and yet you seem to
work completely independently (I really don't care if you work in
different departments - the fact of the matter is you're touching the
same code in completely different ways with zero coordination between
yourselves. That's simply broken workflow.)
For example, Marc's deleting arch/arm/plat-versatile/localtimer.c, but
Pawel is modifying it to add DT support for Versatile Express. The
correct solution? Hell knows. And I don't want a solution to the merge
conflict. I want the merge conflict to go away (because I'm not frigging
around applying the same git-rerere immune fixes to a tree I'm regenerating
each night for the kernel autobuilder.)
I'm getting conflicts in arch/arm/mach-vexpress/ct-ca9x4.c and
arch/arm/mach-ux500/timer.c as well, which I'm not going to bother trying
to sort out - the obvious solution for ux500/timer.c doesn't look right.
I've a mind to drop the localtimer changes on the floor until after this
merge window, but unfortunately they're part of devel-stable so I can't.
Correction: I haven't been pushing out my devel-stable branch for
apparantly two months (according to gitweb, and no one noticed?), so I
_could_ drop the merge of Marc's tree until the conflicts can be sanely
resolved.
I haven't noticed because I stopped tracking your tree directly when
you were having server load issues; I tend to have kept an eye on
linux-next-level breakage instead, but probably not as close as I
should have.
Dropping Marc's branch and having him either resubmit on top of
arm-soc like the io cleanup was done, or pull it in as an early
dependency for 3.5 and stage it in an for-armsoc branch sounds like
two good options to me, with no real preference in either direction.
I'm happy to rebase my patches on anything that will make the merge
easier (IOW conflict-less).
Russell, would you prefer this series to go via armsoc? This seems the
cleanest solution for the time being.
With a lot of these core ARM changes, there's a very fine line between
whether they are core ARM changes or whether they're platform level
changes (many core ARM changes will impact lots of platforms.) I'm just
wondering if there's any point to taking these changes through my tree.
It seems utterly pointless if they're going to keep conflicting with
platform stuff.
From: Marc Zyngier <hidden> Date: 2012-03-13 10:58:33
On 13/03/12 10:15, Russell King - ARM Linux wrote:
On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
quoted
On 13/03/12 01:23, Olof Johansson wrote:
quoted
Hi,
On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
On Mon, Mar 12, 2012 at 11:10:16PM +0000, Russell King - ARM Linux wrote:
quoted
Marc, Pawel,
Your changes are conflicting badly. Seriously badly. So badly that I'm
not bothering to fix the conflicts because I can't work out what the fix
should be.
You both work for the same frigging organization and yet you seem to
work completely independently (I really don't care if you work in
different departments - the fact of the matter is you're touching the
same code in completely different ways with zero coordination between
yourselves. That's simply broken workflow.)
For example, Marc's deleting arch/arm/plat-versatile/localtimer.c, but
Pawel is modifying it to add DT support for Versatile Express. The
correct solution? Hell knows. And I don't want a solution to the merge
conflict. I want the merge conflict to go away (because I'm not frigging
around applying the same git-rerere immune fixes to a tree I'm regenerating
each night for the kernel autobuilder.)
I'm getting conflicts in arch/arm/mach-vexpress/ct-ca9x4.c and
arch/arm/mach-ux500/timer.c as well, which I'm not going to bother trying
to sort out - the obvious solution for ux500/timer.c doesn't look right.
I've a mind to drop the localtimer changes on the floor until after this
merge window, but unfortunately they're part of devel-stable so I can't.
Correction: I haven't been pushing out my devel-stable branch for
apparantly two months (according to gitweb, and no one noticed?), so I
_could_ drop the merge of Marc's tree until the conflicts can be sanely
resolved.
I haven't noticed because I stopped tracking your tree directly when
you were having server load issues; I tend to have kept an eye on
linux-next-level breakage instead, but probably not as close as I
should have.
Dropping Marc's branch and having him either resubmit on top of
arm-soc like the io cleanup was done, or pull it in as an early
dependency for 3.5 and stage it in an for-armsoc branch sounds like
two good options to me, with no real preference in either direction.
I'm happy to rebase my patches on anything that will make the merge
easier (IOW conflict-less).
Russell, would you prefer this series to go via armsoc? This seems the
cleanest solution for the time being.
With a lot of these core ARM changes, there's a very fine line between
whether they are core ARM changes or whether they're platform level
changes (many core ARM changes will impact lots of platforms.) I'm just
wondering if there's any point to taking these changes through my tree.
It seems utterly pointless if they're going to keep conflicting with
platform stuff.
Fair enough.
Olof, Arnd: which is the most base for you to take this series?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
quoted
On 13/03/12 01:23, Olof Johansson wrote:
quoted
Hi,
On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
Correction: I haven't been pushing out my devel-stable branch for
apparantly two months (according to gitweb, and no one noticed?), so I
could drop the merge of Marc's tree until the conflicts can be sanely
resolved.
I haven't noticed because I stopped tracking your tree directly when
you were having server load issues; I tend to have kept an eye on
linux-next-level breakage instead, but probably not as close as I
should have.
Dropping Marc's branch and having him either resubmit on top of
arm-soc like the io cleanup was done, or pull it in as an early
dependency for 3.5 and stage it in an for-armsoc branch sounds like
two good options to me, with no real preference in either direction.
I'm happy to rebase my patches on anything that will make the merge
easier (IOW conflict-less).
Russell, would you prefer this series to go via armsoc? This seems the
cleanest solution for the time being.
With a lot of these core ARM changes, there's a very fine line between
whether they are core ARM changes or whether they're platform level
changes (many core ARM changes will impact lots of platforms.) I'm just
wondering if there's any point to taking these changes through my tree.
It seems utterly pointless if they're going to keep conflicting with
platform stuff.
Fair enough.
Olof, Arnd: which is the most base for you to take this series?
I'm not sure I understand your question. The conflicts that Russell
mentioned are with the ux500/timer (in next/soc) and with the
vexpress/dt (in next/dt) branches. There are multiple ways out of
here:
a) take your series first, but merge it into the next/dt and next/soc
branches, resolving the conflicts in the process. This would be
fairly easy to do if you can provide the merge resolution as
a git pull and let Russell still take your series as is.
b) rebase your series on top of vexpress/dt, merge it into the next/soc
branch.
c) rebase your series on top of ux500/timer, merge it into the next/dt
branch.
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Arnd
From: Marc Zyngier <hidden> Date: 2012-03-13 13:58:58
On 13/03/12 11:55, Arnd Bergmann wrote:
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
quoted
On 13/03/12 01:23, Olof Johansson wrote:
quoted
Hi,
On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
[off-list ref] wrote:
quoted
Correction: I haven't been pushing out my devel-stable branch for
apparantly two months (according to gitweb, and no one noticed?), so I
could drop the merge of Marc's tree until the conflicts can be sanely
resolved.
I haven't noticed because I stopped tracking your tree directly when
you were having server load issues; I tend to have kept an eye on
linux-next-level breakage instead, but probably not as close as I
should have.
Dropping Marc's branch and having him either resubmit on top of
arm-soc like the io cleanup was done, or pull it in as an early
dependency for 3.5 and stage it in an for-armsoc branch sounds like
two good options to me, with no real preference in either direction.
I'm happy to rebase my patches on anything that will make the merge
easier (IOW conflict-less).
Russell, would you prefer this series to go via armsoc? This seems the
cleanest solution for the time being.
With a lot of these core ARM changes, there's a very fine line between
whether they are core ARM changes or whether they're platform level
changes (many core ARM changes will impact lots of platforms.) I'm just
wondering if there's any point to taking these changes through my tree.
It seems utterly pointless if they're going to keep conflicting with
platform stuff.
Fair enough.
Olof, Arnd: which is the most base for you to take this series?
I'm not sure I understand your question. The conflicts that Russell
mentioned are with the ux500/timer (in next/soc) and with the
vexpress/dt (in next/dt) branches. There are multiple ways out of
here:
a) take your series first, but merge it into the next/dt and next/soc
branches, resolving the conflicts in the process. This would be
fairly easy to do if you can provide the merge resolution as
a git pull and let Russell still take your series as is.
b) rebase your series on top of vexpress/dt, merge it into the next/soc
branch.
c) rebase your series on top of ux500/timer, merge it into the next/dt
branch.
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Thanks for doing that Arnd.
I've thus created a new branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
local_timers-for-arm-soc
which contains the arm-soc next/timers branch as well as my local timers
series. I'd greatly appreciate if you could pull it for 3.4.
Thanks again,
M.
--
Jazz is not dead. It just smells funny...
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Thanks for doing that Arnd.
I've thus created a new branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
local_timers-for-arm-soc
which contains the arm-soc next/timers branch as well as my local timers
series. I'd greatly appreciate if you could pull it for 3.4.
I've updated the next/timer branch with your changes now, but did not
put it into the for-next branch because Olof is currently handling that.
Olof, can you add it to for-next please? The timer branch should have
no dependencies other than rmk/for-armsoc, so it can be fairly close to
the start.
Arnd
From: Marc Zyngier <hidden> Date: 2012-03-13 15:00:26
On 13/03/12 14:33, Arnd Bergmann wrote:
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 11:55, Arnd Bergmann wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
quoted
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Thanks for doing that Arnd.
I've thus created a new branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
local_timers-for-arm-soc
which contains the arm-soc next/timers branch as well as my local timers
series. I'd greatly appreciate if you could pull it for 3.4.
I've updated the next/timer branch with your changes now, but did not
put it into the for-next branch because Olof is currently handling that.
Olof, can you add it to for-next please? The timer branch should have
no dependencies other than rmk/for-armsoc, so it can be fairly close to
the start.
Thank you very much guys.
M.
--
Jazz is not dead. It just smells funny...
From: Olof Johansson <hidden> Date: 2012-03-14 00:52:13
On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann [off-list ref] wrote:
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 11:55, Arnd Bergmann wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
quoted
d) create a new next/timer branch in arm-soc that has Pawel's
? ?98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
? ?vexpress/dt, your patches and the ux500/timer series. Also put
? ?98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Thanks for doing that Arnd.
I've thus created a new branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
local_timers-for-arm-soc
which contains the arm-soc next/timers branch as well as my local timers
series. I'd greatly appreciate if you could pull it for 3.4.
I've updated the next/timer branch with your changes now, but did not
put it into the for-next branch because Olof is currently handling that.
Olof, can you add it to for-next please? The timer branch should have
no dependencies other than rmk/for-armsoc, so it can be fairly close to
the start.
Thanks. I merged into for-next, but since there's already a history in
there and I didn't rebuild it, it's on top of everything else.
I got two trivial merge conflicts (and a few that git sorted out
automatically): one with the tegra makefile, the other with shmobile's
timer init.
Marc, please take a look at the next/timers merge in the arm-soc
for-next branch and let me know if they're OK. I'm pretty sure they
are though.
-Olof
From: Marc Zyngier <hidden> Date: 2012-03-14 08:43:39
On 14/03/12 00:52, Olof Johansson wrote:
On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann [off-list ref] wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 11:55, Arnd Bergmann wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
quoted
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Thanks for doing that Arnd.
I've thus created a new branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
local_timers-for-arm-soc
which contains the arm-soc next/timers branch as well as my local timers
series. I'd greatly appreciate if you could pull it for 3.4.
I've updated the next/timer branch with your changes now, but did not
put it into the for-next branch because Olof is currently handling that.
Olof, can you add it to for-next please? The timer branch should have
no dependencies other than rmk/for-armsoc, so it can be fairly close to
the start.
Thanks. I merged into for-next, but since there's already a history in
there and I didn't rebuild it, it's on top of everything else.
I got two trivial merge conflicts (and a few that git sorted out
automatically): one with the tegra makefile, the other with shmobile's
timer init.
Marc, please take a look at the next/timers merge in the arm-soc
for-next branch and let me know if they're OK. I'm pretty sure they
are though.
Had a brief look, and it seems alright to me.
Thanks Olof!
M.
--
Jazz is not dead. It just smells funny...
From: Stephen Rothwell <hidden> Date: 2012-03-15 07:17:18
Hi all,
On Wed, 14 Mar 2012 08:43:39 +0000 Marc Zyngier [off-list ref] wrote:
On 14/03/12 00:52, Olof Johansson wrote:
quoted
On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann [off-list ref] wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 11:55, Arnd Bergmann wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
quoted
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Thanks for doing that Arnd.
I've thus created a new branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
local_timers-for-arm-soc
which contains the arm-soc next/timers branch as well as my local timers
series. I'd greatly appreciate if you could pull it for 3.4.
I've updated the next/timer branch with your changes now, but did not
put it into the for-next branch because Olof is currently handling that.
Olof, can you add it to for-next please? The timer branch should have
no dependencies other than rmk/for-armsoc, so it can be fairly close to
the start.
Thanks. I merged into for-next, but since there's already a history in
there and I didn't rebuild it, it's on top of everything else.
I got two trivial merge conflicts (and a few that git sorted out
automatically): one with the tegra makefile, the other with shmobile's
timer init.
Marc, please take a look at the next/timers merge in the arm-soc
for-next branch and let me know if they're OK. I'm pretty sure they
are though.
Had a brief look, and it seems alright to me.
Thanks Olof!
ok, it looks like Marc's series is now in both the arm and arm-soc trees
(and causing some conflicts due to other changes to the files involved
and some resolved conflicts).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120315/29cf3ba2/attachment.sig>
From: Russell King - ARM Linux <hidden> Date: 2012-03-15 09:21:40
On Thu, Mar 15, 2012 at 06:17:18PM +1100, Stephen Rothwell wrote:
Hi all,
On Wed, 14 Mar 2012 08:43:39 +0000 Marc Zyngier [off-list ref] wrote:
quoted
On 14/03/12 00:52, Olof Johansson wrote:
quoted
On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann [off-list ref] wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 11:55, Arnd Bergmann wrote:
quoted
On Tuesday 13 March 2012, Marc Zyngier wrote:
quoted
On 13/03/12 10:15, Russell King - ARM Linux wrote:
quoted
quoted
d) create a new next/timer branch in arm-soc that has Pawel's
98ed4ceb "ARM: vexpress: Get rid of MMIO_P2V" (the first patch from
vexpress/dt, your patches and the ux500/timer series. Also put
98ed4ceb into the next/cleanup branch.
Any of those will work for us, my preference would be on #4. I have
created the next/timer branch in the arm-soc tree, so you can use
that and either rebase your patches on top or merge your tree into
it and fix up the merge conflicts.
Thanks for doing that Arnd.
I've thus created a new branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
local_timers-for-arm-soc
which contains the arm-soc next/timers branch as well as my local timers
series. I'd greatly appreciate if you could pull it for 3.4.
I've updated the next/timer branch with your changes now, but did not
put it into the for-next branch because Olof is currently handling that.
Olof, can you add it to for-next please? The timer branch should have
no dependencies other than rmk/for-armsoc, so it can be fairly close to
the start.
Thanks. I merged into for-next, but since there's already a history in
there and I didn't rebuild it, it's on top of everything else.
I got two trivial merge conflicts (and a few that git sorted out
automatically): one with the tegra makefile, the other with shmobile's
timer init.
Marc, please take a look at the next/timers merge in the arm-soc
for-next branch and let me know if they're OK. I'm pretty sure they
are though.
Had a brief look, and it seems alright to me.
Thanks Olof!
ok, it looks like Marc's series is now in both the arm and arm-soc trees
(and causing some conflicts due to other changes to the files involved
and some resolved conflicts).
It shouldn't be in my tree anymore - I removed it a couple of days ago
and pushed that out.