Conflict between Versatile Express DT conversion and local timer updates

Conflict between Versatile Express DT conversion and local timer updates

[Russell King - ARM Linux]

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
--- a/arch/arm/mach-ux500/timer.c
+++ b/arch/arm/mach-ux500/timer.c
@@@ -15,38 -15,22 +15,52 @@@
  #include <mach/setup.h>
  #include <mach/hardware.h>
  
 +#ifdef CONFIG_HAVE_ARM_TWD
 +static DEFINE_TWD_LOCAL_TIMER(u5500_twd_local_timer,
 +			      U5500_TWD_BASE, IRQ_LOCALTIMER);
 +static DEFINE_TWD_LOCAL_TIMER(u8500_twd_local_timer,
 +			      U8500_TWD_BASE, IRQ_LOCALTIMER);
 +
 +static void __init ux500_twd_init(void)
 +{
 +	struct twd_local_timer *twd_local_timer;
 +	int err;
 +
 +	twd_local_timer = cpu_is_u5500() ? &u5500_twd_local_timer :
 +					   &u8500_twd_local_timer;
 +
 +	err = twd_local_timer_register(twd_local_timer);
 +	if (err)
 +		pr_err("twd_local_timer_register failed %d\n", err);
 +}
 +#else
 +#define ux500_twd_init()	do { } while(0)
 +#endif
 +
  static void __init ux500_timer_init(void)
  {
+ 	void __iomem *mtu_timer_base;
  	void __iomem *prcmu_timer_base;
 +	int err;
  
  	if (cpu_is_u5500()) {
++<<<<<<< HEAD
 +		mtu_base = __io_address(U5500_MTU0_BASE);
 +		prcmu_timer_base = __io_address(U5500_PRCMU_TIMER_3_BASE);
 +	} else if (cpu_is_u8500()) {
 +		mtu_base = __io_address(U8500_MTU0_BASE);
++=======
+ #ifdef CONFIG_LOCAL_TIMERS
+ 		twd_base = __io_address(U5500_TWD_BASE);
+ #endif
+ 		mtu_timer_base = __io_address(U5500_MTU0_BASE);
+ 		prcmu_timer_base = __io_address(U5500_PRCMU_TIMER_3_BASE);
+ 	} else if (cpu_is_u8500()) {
+ #ifdef CONFIG_LOCAL_TIMERS
+ 		twd_base = __io_address(U8500_TWD_BASE);
+ #endif
+ 		mtu_timer_base = __io_address(U8500_MTU0_BASE);
++>>>>>>> arm-soc
  		prcmu_timer_base = __io_address(U8500_PRCMU_TIMER_4_BASE);
  	} else {
  		ux500_unknown_soc();
@@@ -69,9 -53,8 +83,9 @@@
  	 *
  	 */
  
- 	nmdk_timer_init();
+ 	nmdk_timer_init(mtu_timer_base);
  	clksrc_dbx500_prcmu_init(prcmu_timer_base);
 +	ux500_twd_init();
  }
  
  static void ux500_timer_reset(void)
diff --cc arch/arm/mach-vexpress/ct-ca9x4.c
index b391538,73791f0..0000000
--- a/arch/arm/mach-vexpress/ct-ca9x4.c
+++ b/arch/arm/mach-vexpress/ct-ca9x4.c
@@@ -54,44 -42,17 +42,50 @@@ static struct map_desc ct_ca9x4_io_desc
  static void __init ct_ca9x4_map_io(void)
  {
  	iotable_init(ct_ca9x4_io_desc, ARRAY_SIZE(ct_ca9x4_io_desc));
++<<<<<<< HEAD
++=======
+ #ifdef CONFIG_LOCAL_TIMERS
+ 	twd_base = ioremap(A9_MPCORE_TWD, SZ_32);
+ #endif
++>>>>>>> arm-soc
  }
  
 +#ifdef CONFIG_HAVE_ARM_TWD
 +static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, A9_MPCORE_TWD, IRQ_LOCALTIMER);
 +
 +static void __init ca9x4_twd_init(void)
 +{
 +	int err = twd_local_timer_register(&twd_local_timer);
 +	if (err)
 +		pr_err("twd_local_timer_register failed %d\n", err);
 +}
 +#else
 +#define ca9x4_twd_init()	do {} while(0)
 +#endif
 +
  static void __init ct_ca9x4_init_irq(void)
  {
++<<<<<<< HEAD
 +	gic_init(0, 29, MMIO_P2V(A9_MPCORE_GIC_DIST),
 +		 MMIO_P2V(A9_MPCORE_GIC_CPU));
 +	ca9x4_twd_init();
 +}
 +
 +#if 0
 +static void __init ct_ca9x4_timer_init(void)
 +{
 +	writel(0, MMIO_P2V(CT_CA9X4_TIMER0) + TIMER_CTRL);
 +	writel(0, MMIO_P2V(CT_CA9X4_TIMER1) + TIMER_CTRL);
 +
 +	sp804_clocksource_init(MMIO_P2V(CT_CA9X4_TIMER1), "ct-timer1");
 +	sp804_clockevents_init(MMIO_P2V(CT_CA9X4_TIMER0), IRQ_CT_CA9X4_TIMER0,
 +		"ct-timer0");
++=======
+ 	gic_init(0, 29, ioremap(A9_MPCORE_GIC_DIST, SZ_4K),
+ 		 ioremap(A9_MPCORE_GIC_CPU, SZ_256));
++>>>>>>> arm-soc
  }
  
- static struct sys_timer ct_ca9x4_timer = {
- 	.init	= ct_ca9x4_timer_init,
- };
- #endif
- 
  static void ct_ca9x4_clcd_enable(struct clcd_fb *fb)
  {
  	v2m_cfg_write(SYS_CFG_MUXFPGA | SYS_CFG_SITE_DB1, 0);

Conflict between Versatile Express DT conversion and local timer updates

[Russell King - ARM Linux]

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.

> 
> 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
> --- a/arch/arm/mach-ux500/timer.c
> +++ b/arch/arm/mach-ux500/timer.c
> @@@ -15,38 -15,22 +15,52 @@@
>   #include <mach/setup.h>
>   #include <mach/hardware.h>
>   
>  +#ifdef CONFIG_HAVE_ARM_TWD
>  +static DEFINE_TWD_LOCAL_TIMER(u5500_twd_local_timer,
>  +			      U5500_TWD_BASE, IRQ_LOCALTIMER);
>  +static DEFINE_TWD_LOCAL_TIMER(u8500_twd_local_timer,
>  +			      U8500_TWD_BASE, IRQ_LOCALTIMER);
>  +
>  +static void __init ux500_twd_init(void)
>  +{
>  +	struct twd_local_timer *twd_local_timer;
>  +	int err;
>  +
>  +	twd_local_timer = cpu_is_u5500() ? &u5500_twd_local_timer :
>  +					   &u8500_twd_local_timer;
>  +
>  +	err = twd_local_timer_register(twd_local_timer);
>  +	if (err)
>  +		pr_err("twd_local_timer_register failed %d\n", err);
>  +}
>  +#else
>  +#define ux500_twd_init()	do { } while(0)
>  +#endif
>  +
>   static void __init ux500_timer_init(void)
>   {
> + 	void __iomem *mtu_timer_base;
>   	void __iomem *prcmu_timer_base;
>  +	int err;
>   
>   	if (cpu_is_u5500()) {
> ++<<<<<<< HEAD
>  +		mtu_base = __io_address(U5500_MTU0_BASE);
>  +		prcmu_timer_base = __io_address(U5500_PRCMU_TIMER_3_BASE);
>  +	} else if (cpu_is_u8500()) {
>  +		mtu_base = __io_address(U8500_MTU0_BASE);
> ++=======
> + #ifdef CONFIG_LOCAL_TIMERS
> + 		twd_base = __io_address(U5500_TWD_BASE);
> + #endif
> + 		mtu_timer_base = __io_address(U5500_MTU0_BASE);
> + 		prcmu_timer_base = __io_address(U5500_PRCMU_TIMER_3_BASE);
> + 	} else if (cpu_is_u8500()) {
> + #ifdef CONFIG_LOCAL_TIMERS
> + 		twd_base = __io_address(U8500_TWD_BASE);
> + #endif
> + 		mtu_timer_base = __io_address(U8500_MTU0_BASE);
> ++>>>>>>> arm-soc
>   		prcmu_timer_base = __io_address(U8500_PRCMU_TIMER_4_BASE);
>   	} else {
>   		ux500_unknown_soc();
> @@@ -69,9 -53,8 +83,9 @@@
>   	 *
>   	 */
>   
> - 	nmdk_timer_init();
> + 	nmdk_timer_init(mtu_timer_base);
>   	clksrc_dbx500_prcmu_init(prcmu_timer_base);
>  +	ux500_twd_init();
>   }
>   
>   static void ux500_timer_reset(void)
> diff --cc arch/arm/mach-vexpress/ct-ca9x4.c
> index b391538,73791f0..0000000
> --- a/arch/arm/mach-vexpress/ct-ca9x4.c
> +++ b/arch/arm/mach-vexpress/ct-ca9x4.c
> @@@ -54,44 -42,17 +42,50 @@@ static struct map_desc ct_ca9x4_io_desc
>   static void __init ct_ca9x4_map_io(void)
>   {
>   	iotable_init(ct_ca9x4_io_desc, ARRAY_SIZE(ct_ca9x4_io_desc));
> ++<<<<<<< HEAD
> ++=======
> + #ifdef CONFIG_LOCAL_TIMERS
> + 	twd_base = ioremap(A9_MPCORE_TWD, SZ_32);
> + #endif
> ++>>>>>>> arm-soc
>   }
>   
>  +#ifdef CONFIG_HAVE_ARM_TWD
>  +static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, A9_MPCORE_TWD, IRQ_LOCALTIMER);
>  +
>  +static void __init ca9x4_twd_init(void)
>  +{
>  +	int err = twd_local_timer_register(&twd_local_timer);
>  +	if (err)
>  +		pr_err("twd_local_timer_register failed %d\n", err);
>  +}
>  +#else
>  +#define ca9x4_twd_init()	do {} while(0)
>  +#endif
>  +
>   static void __init ct_ca9x4_init_irq(void)
>   {
> ++<<<<<<< HEAD
>  +	gic_init(0, 29, MMIO_P2V(A9_MPCORE_GIC_DIST),
>  +		 MMIO_P2V(A9_MPCORE_GIC_CPU));
>  +	ca9x4_twd_init();
>  +}
>  +
>  +#if 0
>  +static void __init ct_ca9x4_timer_init(void)
>  +{
>  +	writel(0, MMIO_P2V(CT_CA9X4_TIMER0) + TIMER_CTRL);
>  +	writel(0, MMIO_P2V(CT_CA9X4_TIMER1) + TIMER_CTRL);
>  +
>  +	sp804_clocksource_init(MMIO_P2V(CT_CA9X4_TIMER1), "ct-timer1");
>  +	sp804_clockevents_init(MMIO_P2V(CT_CA9X4_TIMER0), IRQ_CT_CA9X4_TIMER0,
>  +		"ct-timer0");
> ++=======
> + 	gic_init(0, 29, ioremap(A9_MPCORE_GIC_DIST, SZ_4K),
> + 		 ioremap(A9_MPCORE_GIC_CPU, SZ_256));
> ++>>>>>>> arm-soc
>   }
>   
> - static struct sys_timer ct_ca9x4_timer = {
> - 	.init	= ct_ca9x4_timer_init,
> - };
> - #endif
> - 
>   static void ct_ca9x4_clcd_enable(struct clcd_fb *fb)
>   {
>   	v2m_cfg_write(SYS_CFG_MUXFPGA | SYS_CFG_SITE_DB1, 0);
> 

Conflict between Versatile Express DT conversion and local timer updates

[Olof Johansson]

Hi,

On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> 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.

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

Conflict between Versatile Express DT conversion and local timer updates

[Marc Zyngier]

On 13/03/12 01:23, Olof Johansson wrote:
> Hi,
> 
> On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> 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.
> 
> 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...

Conflict between Versatile Express DT conversion and local timer updates

[Russell King - ARM Linux]

On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
> On 13/03/12 01:23, Olof Johansson wrote:
> > Hi,
> > 
> > On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> 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.
> > 
> > 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.

Conflict between Versatile Express DT conversion and local timer updates

[Marc Zyngier]

On 13/03/12 10:15, Russell King - ARM Linux wrote:
> On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
>> On 13/03/12 01:23, Olof Johansson wrote:
>>> Hi,
>>>
>>> On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>>> 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.
>>>
>>> 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...

Conflict between Versatile Express DT conversion and local timer updates

[Arnd Bergmann]

On Tuesday 13 March 2012, Marc Zyngier wrote:
> On 13/03/12 10:15, Russell King - ARM Linux wrote:
> > On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
> >> On 13/03/12 01:23, Olof Johansson wrote:
> >>> Hi,
> >>>
> >>> On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
> >>> <linux@arm.linux.org.uk> wrote:
> >>>>
> >>>> 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

Conflict between Versatile Express DT conversion and local timer updates

[Marc Zyngier]

On 13/03/12 11:55, Arnd Bergmann wrote:
> On Tuesday 13 March 2012, Marc Zyngier wrote:
>> On 13/03/12 10:15, Russell King - ARM Linux wrote:
>>> On Tue, Mar 13, 2012 at 09:39:57AM +0000, Marc Zyngier wrote:
>>>> On 13/03/12 01:23, Olof Johansson wrote:
>>>>> Hi,
>>>>>
>>>>> On Mon, Mar 12, 2012 at 4:59 PM, Russell King - ARM Linux
>>>>> <linux@arm.linux.org.uk> wrote:
>>>>>>
>>>>>> 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...

Conflict between Versatile Express DT conversion and local timer updates

[Arnd Bergmann]

On Tuesday 13 March 2012, Marc Zyngier wrote:
> On 13/03/12 11:55, Arnd Bergmann wrote:
> > On Tuesday 13 March 2012, Marc Zyngier wrote:
> >> On 13/03/12 10:15, Russell King - ARM Linux wrote:

> > 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

Conflict between Versatile Express DT conversion and local timer updates

[Marc Zyngier]

On 13/03/12 14:33, Arnd Bergmann wrote:
> On Tuesday 13 March 2012, Marc Zyngier wrote:
>> On 13/03/12 11:55, Arnd Bergmann wrote:
>>> On Tuesday 13 March 2012, Marc Zyngier wrote:
>>>> On 13/03/12 10:15, Russell King - ARM Linux wrote:
> 
>>> 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...

Conflict between Versatile Express DT conversion and local timer updates

[Olof Johansson]

On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 13 March 2012, Marc Zyngier wrote:
>> On 13/03/12 11:55, Arnd Bergmann wrote:
>> > On Tuesday 13 March 2012, Marc Zyngier wrote:
>> >> On 13/03/12 10:15, Russell King - ARM Linux wrote:
>
>> > 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

Conflict between Versatile Express DT conversion and local timer updates

[Marc Zyngier]

On 14/03/12 00:52, Olof Johansson wrote:
> On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 13 March 2012, Marc Zyngier wrote:
>>> On 13/03/12 11:55, Arnd Bergmann wrote:
>>>> On Tuesday 13 March 2012, Marc Zyngier wrote:
>>>>> On 13/03/12 10:15, Russell King - ARM Linux wrote:
>>
>>>> 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...

Conflict between Versatile Express DT conversion and local timer updates

[Stephen Rothwell]

Hi all,

On Wed, 14 Mar 2012 08:43:39 +0000 Marc Zyngier <marc.zyngier@arm.com> wrote:
>
> On 14/03/12 00:52, Olof Johansson wrote:
> > On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tuesday 13 March 2012, Marc Zyngier wrote:
> >>> On 13/03/12 11:55, Arnd Bergmann wrote:
> >>>> On Tuesday 13 March 2012, Marc Zyngier wrote:
> >>>>> On 13/03/12 10:15, Russell King - ARM Linux wrote:
> >>
> >>>> 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>

Conflict between Versatile Express DT conversion and local timer updates

[Russell King - ARM Linux]

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 <marc.zyngier@arm.com> wrote:
> >
> > On 14/03/12 00:52, Olof Johansson wrote:
> > > On Tue, Mar 13, 2012 at 7:33 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > >> On Tuesday 13 March 2012, Marc Zyngier wrote:
> > >>> On 13/03/12 11:55, Arnd Bergmann wrote:
> > >>>> On Tuesday 13 March 2012, Marc Zyngier wrote:
> > >>>>> On 13/03/12 10:15, Russell King - ARM Linux wrote:
> > >>
> > >>>> 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.

Conflict between Versatile Express DT conversion and local timer updates

[Russell King - ARM Linux]

On Thu, Mar 15, 2012 at 09:21:40AM +0000, Russell King - ARM Linux wrote:
> It shouldn't be in my tree anymore - I removed it a couple of days ago
> and pushed that out.

Sorry, it didn't get pushed out (the last push was 10 mins before I
removed it.  So yes, you're right.  Should be gone in your next pull.

Conflict between Versatile Express DT conversion and local timer updates

[Stephen Rothwell]

Hi Russell,

On Thu, 15 Mar 2012 09:36:15 +0000 Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> On Thu, Mar 15, 2012 at 09:21:40AM +0000, Russell King - ARM Linux wrote:
> > It shouldn't be in my tree anymore - I removed it a couple of days ago
> > and pushed that out.
> 
> Sorry, it didn't get pushed out (the last push was 10 mins before I
> removed it.  So yes, you're right.  Should be gone in your next pull.

Thanks for that.

-- 
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/b7f02718/attachment.sig>