From mboxrd@z Thu Jan  1 00:00:00 1970
From: tony@atomide.com (Tony Lindgren)
Date: Mon, 27 Jun 2011 00:48:57 -0700
Subject: [PATCH 07/10] omap2+: Reserve clocksource and timesource and
	initialize dmtimer later
In-Reply-To: <87wrgca3dr.fsf@ti.com>
References: <20110620091754.357.56441.stgit@kaulin>
	<20110620092343.357.60445.stgit@kaulin> <87wrgca3dr.fsf@ti.com>
Message-ID: <20110627074856.GD23145@atomide.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

* Kevin Hilman <khilman@ti.com> [110623 09:56]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > There's no need to initialize the dmtimer framework early.
> 
> Actually, there is, because it's being used from the early code.
> 
> The sys_timer.init functions are called before arch_initcalls, so before
> omap_dm_timer_init() is called, you have:
> 
> omap3_timer_init()
>     omap2_gp_clockevent_init()
>         omap_dm_timer_init_one()
>            omap_dm_timer_request_specific()
>                
> 
> Among other things, the spinlock is taken before it has been initialized
> in omap_dm_timer_init() (that's how I noticed this problem), but the
> rest of the init of course hasn't been done either.
> 
> Basically, the problem is that this "early init" code is not only using
> the new macros, but it's also using functions from the "real" driver,
> which is not yet initialized.

Sounds like you did not apply the previous patch to remove the PM hack?

There's no need to call to omap_dm_timer_request_specific here unless
you added back the PM hack.

Regards,

Tony