>>-----Original Message-----
>>From: Kevin Hilman [mailto:[email protected]]
>>Sent: Thursday, July 01, 2010 2:09 AM
>>To: Gopinath, Thara
>>Cc: [email protected]; [email protected]
>>Subject: Re: [PATCH v2 10/13] OMAP: create omap_devices for MPU, DSP, L3
>>
>>"Gopinath, Thara" <[email protected]> writes:
>>
>>[...]
>>
>>>>>+static int __init omap_common_pm_init(void)
>>>>>+{
>>>>>+ omap_init_processor_devices();
>>>>>+ omap_pm_if_init();
>>>>>+
>>>>>+ return 0;
>>>>>+}
>>>>>+device_initcall(omap_common_pm_init);
>>
>>>
>>> But I guess opp layer is still getting initialized before this. Esp if
>>> the board files are initializing the opp structures. Or do you have a
>>> patch to fix it in some other branch ?
>>>
>>
>>The common OPP init will be done in this function as well (see current
>>PM branch.) Board files no longer do OPP init (by default) as it is
>>handled by common code. Only boards that add OPPs need to call the init
>>function, and we'll have to figure out way to handle that late.
Yes you are correct. The common OPP init is done in this function. One other
thing I am a bit worried about is the order of initializations. The order
should be
Opp layer
Voltage layer
Smartreflex device layer.
Presently all three layers are device_initcalls. The sequence is maintained due
to the way these drivers are compiled in. We need to make them work independent
of the way the drivers are compiled.
One way is to have the omap_common_pm_init call into the inits of all these
layers sequentially and
remove the separate init calls. Any other suggestion anyone?
Kevin, by the way your latest pm-sr branch with the above changes works. I
tested it yesterday.
Regards
Thara
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
