[PATCH 07/10] omap2+: Reserve clocksource and timesource and initialize dmtimer later

Kevin Hilman khilman at ti.com
Mon Jun 27 12:41:09 EDT 2011


Tony Lindgren <tony at atomide.com> writes:

> * Kevin Hilman <khilman at ti.com> [110623 09:56]:
>> Tony Lindgren <tony at 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.

Right, I added it back not noticing that it also removed the
_request_specific call.

Thanks for the clarification,

Kevin



More information about the linux-arm-kernel mailing list