* Cousson, Benoit <b-cousson@xxxxxx> [110221 14:51]:
> On 2/21/2011 11:08 PM, Tony Lindgren wrote:
> >
> >Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be
> >caused by the timer patch, the following fixes it. How do you want
> >to deal with fixing this issue?
>
> I guess it is due to the early_init change?
Yes that seems to be the case.
> I have some concern bypassing hwmod to handle system timer. The
> idea, before the introduction of the early_init, was to use hwmod
> for early initialization as well including timers. It will become a
> little bit harder now :-(
If we get rid of the system timer dependency to hwmod we can
pretty much initialize everything later on and don't need to
use early_init stuff at all.
> I still didn't fully understand the rational behind that early_init
> for timer BTW.
I'm currently thinking that we should just have omap[234]_init_timer
functions that do not depend on hwmod at all.
> Meanwhile, the following will just prevent the fmwk to reset and
> idle the timer during hwmod_init.
That seems like a good to fix for now until the hwmod timer
changes are sorted out.
Tony
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
> *omap44xx_timer1_slaves[] = {
> static struct omap_hwmod omap44xx_timer1_hwmod = {
> .name = "timer1",
> .class = &omap44xx_timer_1ms_hwmod_class,
> + .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
> .mpu_irqs = omap44xx_timer1_irqs,
> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
> .main_clk = "timer1_fck",
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
