I would suspect, based on work on the kzm9g, that the problem relates to driver initialisation order. In the case of kzm9g my recollection is that the problem was resolved by initialising clocksources earlier by changing their initcall level.

Laurent Pinchart

author

2013-05-15 01:05 UTC #2 lore raw

In reply to Laurent Pinchart

Hi Simon,

Quoted 9 lines · On Wednesday 15 May 2013 09:23:59 Simon Horman wrote:

Quoted 1 line · Laurent Pinchart
But marzen does (renesas-next-20130513). Is that a known issue ?
No, I was not aware of that.
I would suspect, based on work on the kzm9g, that the problem relates to driver initialisation order. In the case of kzm9g my recollection is that the problem was resolved by initialising clocksources earlier by changing their initcall level.

Did that reach mainline ? I've tried booting kzm9g-reference with CONFIG_PREEMPT and have been unable to boot it as well with renesas- next-20130513. Maybe we should enable CONFIG_PREEMPT by default to catch similar issues in the future.

Signature · 3 lines

Regards,

Laurent Pinchart

Simon Horman

2013-05-15 01:29 UTC #3 lore raw

In reply to Laurent Pinchart

Quoted 13 lines · Laurent Pinchart

Hi Simon,
Quoted 9 lines · On Wednesday 15 May 2013 09:23:59 Simon Horman wrote:
Quoted 1 line · Laurent Pinchart
But marzen does (renesas-next-20130513). Is that a known issue ?
No, I was not aware of that.
I would suspect, based on work on the kzm9g, that the problem relates to driver initialisation order. In the case of kzm9g my recollection is that the problem was resolved by initialising clocksources earlier by changing their initcall level.

Quoted 4 lines

Did that reach mainline ? I've tried booting kzm9g-reference with CONFIG_PREEMPT and have been unable to boot it as well with renesas- next-20130513. Maybe we should enable CONFIG_PREEMPT by default to catch similar issues in the future.

It made it into 3.10-rc1 and has been in next for a while now. So it seems that you have found a different problem.

I'm ambivalent to setting CONFIG_PREEMPT by default.

Simon Horman

2013-05-15 03:47 UTC #4 lore raw

In reply to Laurent Pinchart

Quoted 19 lines · Simon Horman

Quoted 13 lines · Laurent Pinchart
Hi Simon,
Quoted 9 lines · On Wednesday 15 May 2013 09:23:59 Simon Horman wrote:
Quoted 1 line · Laurent Pinchart
But marzen does (renesas-next-20130513). Is that a known issue ?
No, I was not aware of that.
I would suspect, based on work on the kzm9g, that the problem relates to driver initialisation order. In the case of kzm9g my recollection is that the problem was resolved by initialising clocksources earlier by changing their initcall level.
Quoted 4 lines
Did that reach mainline ? I've tried booting kzm9g-reference with CONFIG_PREEMPT and have been unable to boot it as well with renesas- next-20130513. Maybe we should enable CONFIG_PREEMPT by default to catch similar issues in the future.

Quoted 4 lines

It made it into 3.10-rc1 and has been in next for a while now. So it seems that you have found a different problem.
I'm ambivalent to setting CONFIG_PREEMPT by default.

Hi Laurent,

I have not been able to pin-point the cause of this problem nor come up with a fix. However, it does seem to be related to the early initialisation of devices and the following work around does allow booting marzen-reference with CONFIG_PREEMPT.

arch/arm/mach-shmobile/board-marzen-reference.c +2 -1

index f83b6d1..ac24cd7 100644
@@ -72,10 +72,11 @@ void __init marzen_init_irq(void)
 DT_MACHINE_START(MARZEN, "marzen")
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
-	.init_early	= r8a7779_init_delay,
+	.init_early	= r8a7779_add_early_devices,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= marzen_init_irq,
 	.init_machine	= marzen_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= marzen_boards_compat_dt,
+	.init_time      = r8a7779_earlytimer_init,
 MACHINE_END

Laurent Pinchart

author

2013-05-15 11:30 UTC #5 lore raw

In reply to Laurent Pinchart

Hi Simon,

Quoted 21 lines · On Wednesday 15 May 2013 12:47:16 Simon Horman wrote:

Quoted 20 lines · Simon Horman
Quoted 11 lines · Laurent Pinchart
Quoted 9 lines · On Wednesday 15 May 2013 09:23:59 Simon Horman wrote:
Quoted 1 line · Laurent Pinchart
But marzen does (renesas-next-20130513). Is that a known issue ?
No, I was not aware of that.
I would suspect, based on work on the kzm9g, that the problem relates to driver initialisation order. In the case of kzm9g my recollection is that the problem was resolved by initialising clocksources earlier by changing their initcall level.
Quoted 4 lines
Did that reach mainline ? I've tried booting kzm9g-reference with CONFIG_PREEMPT and have been unable to boot it as well with renesas- next-20130513. Maybe we should enable CONFIG_PREEMPT by default to catch similar issues in the future.
It made it into 3.10-rc1 and has been in next for a while now. So it seems that you have found a different problem.

Quoted 8 lines

Quoted 1 line
I'm ambivalent to setting CONFIG_PREEMPT by default.
Hi Laurent,
I have not been able to pin-point the cause of this problem nor come up with a fix. However, it does seem to be related to the early initialisation of devices and the following work around does allow booting marzen-reference with CONFIG_PREEMPT.

Thank you for the workaround. What prevents this patch (or a similar patch, as it seems the SCIF and TMU devices would be instantiated twice) from being applied to mainline ? Do we have a plan regarding what code we want to keep in mach-shmobile and what we want to move to DT ?

Quoted 18 lines

(quoted diff) +0 -0

b/arch/arm/mach-shmobile/board-marzen-reference.c index f83b6d1..ac24cd7 100644

arch/arm/mach-shmobile/board-marzen-reference.c +2 -1

@@ -72,10 +72,11 @@ void __init marzen_init_irq(void)
 DT_MACHINE_START(MARZEN, "marzen")
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
-	.init_early	= r8a7779_init_delay,
+	.init_early	= r8a7779_add_early_devices,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= marzen_init_irq,
 	.init_machine	= marzen_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= marzen_boards_compat_dt,
+	.init_time      = r8a7779_earlytimer_init,
 MACHINE_END

Signature · 3 lines

Regards,

Laurent Pinchart

Simon Horman

2013-05-16 01:05 UTC #6 lore raw

In reply to Laurent Pinchart

[ Cc Magnus ]

Quoted 33 lines · Laurent Pinchart

Hi Simon,
Quoted 21 lines · On Wednesday 15 May 2013 12:47:16 Simon Horman wrote:
Quoted 20 lines · Simon Horman
Quoted 11 lines · Laurent Pinchart
Quoted 9 lines · On Wednesday 15 May 2013 09:23:59 Simon Horman wrote:
Quoted 1 line · Laurent Pinchart
But marzen does (renesas-next-20130513). Is that a known issue ?
No, I was not aware of that.
I would suspect, based on work on the kzm9g, that the problem relates to driver initialisation order. In the case of kzm9g my recollection is that the problem was resolved by initialising clocksources earlier by changing their initcall level.
Quoted 4 lines
Did that reach mainline ? I've tried booting kzm9g-reference with CONFIG_PREEMPT and have been unable to boot it as well with renesas- next-20130513. Maybe we should enable CONFIG_PREEMPT by default to catch similar issues in the future.
It made it into 3.10-rc1 and has been in next for a while now. So it seems that you have found a different problem.
Quoted 8 lines
Quoted 1 line
I'm ambivalent to setting CONFIG_PREEMPT by default.
Hi Laurent,
I have not been able to pin-point the cause of this problem nor come up with a fix. However, it does seem to be related to the early initialisation of devices and the following work around does allow booting marzen-reference with CONFIG_PREEMPT.

Quoted 4 lines

Thank you for the workaround. What prevents this patch (or a similar patch, as it seems the SCIF and TMU devices would be instantiated twice) from being applied to mainline ? Do we have a plan regarding what code we want to keep in mach-shmobile and what we want to move to DT ?

Magnus has indicated several times that he would like to avoid using early timers and devices unless they are absolutely necessary. So it seems that this issue should be investigated more thoroughly before pushing this workaround into mainline.

Quoted 24 lines

Quoted 19 lines

(quoted diff) +0 -0

b/arch/arm/mach-shmobile/board-marzen-reference.c index f83b6d1..ac24cd7 100644

arch/arm/mach-shmobile/board-marzen-reference.c +2 -1

@@ -72,10 +72,11 @@ void __init marzen_init_irq(void)
 DT_MACHINE_START(MARZEN, "marzen")
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
-	.init_early	= r8a7779_init_delay,
+	.init_early	= r8a7779_add_early_devices,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= marzen_init_irq,
 	.init_machine	= marzen_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= marzen_boards_compat_dt,
+	.init_time      = r8a7779_earlytimer_init,
 MACHINE_END

Signature · 3 lines

Regards,

Laurent Pinchart

Simon Horman

2013-05-16 03:47 UTC #7 lore raw

In reply to Laurent Pinchart

Quoted 41 lines · Simon Horman

[ Cc Magnus ]
Quoted 33 lines · Laurent Pinchart
Hi Simon,
Quoted 21 lines · On Wednesday 15 May 2013 12:47:16 Simon Horman wrote:
Quoted 20 lines · Simon Horman
Quoted 11 lines · Laurent Pinchart
Quoted 9 lines · On Wednesday 15 May 2013 09:23:59 Simon Horman wrote:
Quoted 1 line · Laurent Pinchart
But marzen does (renesas-next-20130513). Is that a known issue ?
No, I was not aware of that.
I would suspect, based on work on the kzm9g, that the problem relates to driver initialisation order. In the case of kzm9g my recollection is that the problem was resolved by initialising clocksources earlier by changing their initcall level.
Quoted 4 lines
Did that reach mainline ? I've tried booting kzm9g-reference with CONFIG_PREEMPT and have been unable to boot it as well with renesas- next-20130513. Maybe we should enable CONFIG_PREEMPT by default to catch similar issues in the future.
It made it into 3.10-rc1 and has been in next for a while now. So it seems that you have found a different problem.
Quoted 8 lines
Quoted 1 line
I'm ambivalent to setting CONFIG_PREEMPT by default.
Hi Laurent,
I have not been able to pin-point the cause of this problem nor come up with a fix. However, it does seem to be related to the early initialisation of devices and the following work around does allow booting marzen-reference with CONFIG_PREEMPT.
Quoted 4 lines
Thank you for the workaround. What prevents this patch (or a similar patch, as it seems the SCIF and TMU devices would be instantiated twice) from being applied to mainline ? Do we have a plan regarding what code we want to keep in mach-shmobile and what we want to move to DT ?

Quoted 4 lines

Magnus has indicated several times that he would like to avoid using early timers and devices unless they are absolutely necessary. So it seems that this issue should be investigated more thoroughly before pushing this workaround into mainline.

Anecdotally, this work-around seems to be needed for SMSC ethernet to work in on top of v3.10-rc1.

Quoted 18 lines

(quoted diff) +0 -0

b/arch/arm/mach-shmobile/board-marzen-reference.c index f83b6d1..ac24cd7 100644

arch/arm/mach-shmobile/board-marzen-reference.c +2 -1

@@ -72,10 +72,11 @@ void __init marzen_init_irq(void)
 DT_MACHINE_START(MARZEN, "marzen")
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
-	.init_early	= r8a7779_init_delay,
+	.init_early	= r8a7779_add_early_devices,
 	.nr_irqs	= NR_IRQS_LEGACY,
 	.init_irq	= marzen_init_irq,
 	.init_machine	= marzen_init,
 	.init_time	= shmobile_timer_init,
 	.dt_compat	= marzen_boards_compat_dt,
+	.init_time      = r8a7779_earlytimer_init,
 MACHINE_END