> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Gopinath, Thara > Sent: Thursday, July 01, 2010 9:35 AM > To: Kevin Hilman > Cc: linux-omap@xxxxxxxxxxxxxxx; paul@xxxxxxxxx > Subject: RE: [PATCH v2 10/13] OMAP: create omap_devices for MPU, DSP, L3 > > > > >>-----Original Message----- > >>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > >>Sent: Thursday, July 01, 2010 2:09 AM > >>To: Gopinath, Thara > >>Cc: linux-omap@xxxxxxxxxxxxxxx; paul@xxxxxxxxx > >>Subject: Re: [PATCH v2 10/13] OMAP: create omap_devices for MPU, DSP, L3 > >> > >>"Gopinath, Thara" <thara@xxxxxx> 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? > Grouping the initcalls is good idea but with this you can never be able to build any of these as loadable modules. This is valid only if any of above you plan to build as loadable module > 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
