"Gopinath, Thara" <thara@xxxxxx> writes: >>>-----Original Message----- >>>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>>Sent: Wednesday, June 23, 2010 8:19 PM >>>To: Gopinath, Thara >>>Cc: linux-omap@xxxxxxxxxxxxxxx; Menon, Nishanth; Cousson, Benoit >>>Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3 >>> >>>"Gopinath, Thara" <thara@xxxxxx> writes: >>> >>>>>>-----Original Message----- >>>>>>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>>>>>Sent: Thursday, June 17, 2010 5:47 AM >>>>>>To: linux-omap@xxxxxxxxxxxxxxx >>>>>>Cc: Menon, Nishanth; Gopinath, Thara; Cousson, Benoit >>>>>>Subject: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3 >>>>>> >>>>>>Create simple omap_devices for the main processors and busses. >>>>>> >>>>>>This is required to support the forth-coming device-based OPP >>>>>>approach, where OPPs are managed and tracked at the omap_device and >>>>>>hwmod level. >>>>>> >>>>>>Because these omap_devices are based on platform_devices, they cannot >>>>>>be created until the driver core has been initialized. Therefore, move >>>>>>the init of these into a device_initcall(). Also, OMAP PM init cannot >>>>>>be done until after this step as it depends on the OPP layer. >>>>>> >>>>>>Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> >>>[...] >>> >>>>>>+ >>>>>>+static int __init omap2_late_common_init(void) >>>>>>+{ >>>>>>+ omap_init_processor_devices(); >>>>>>+ >>>>>> /* initialize the opp table if board file has not done so */ >>>>>> omap3_pm_init_opp_table(); >>>>>> >>>>>>+ omap_pm_if_init(); >>>>>>+ >>>>>>+ return 0; >>>>>>+} >>>>>>+device_initcall(omap2_late_common_init); >>>> Hello Kevin, >>>> >>>> Any particular reason for making this a late init and not keeping >>>> this a part of init_common_hw? The reason is the board files also >>>> have an option of calling/ overriding omap3_pm_init_opp_table. This >>>> happens really early in init_irq. (Refer board_3430sdp.c). So if a >>>> board file calls into omap3_pm_init_opp_table, the opp >>>> initializations will happen before the omap_device pointers are >>>> build for mpu, iva and l3. So the dev pointers stored as part of >>>> dev_opp tables will be screwed up. My personal preference would be >>>> to call the omap_init_processor_devices just after >>>> hwmod_late_init. This will remove any race conditions as above. >>> >>>I agree, I changed this yesterday and the current pm-wip/hwmods is >>>doing exactly this. >>> >>>The initial reason for the late initcall was because omap_device_build >>>creates platform_devices and devices, but the driver core was not >>>yet initialized at this point. >>> >>>To fix, I now create these devices as early platform devices so that >>>the init sequence can remain the same. >>> >>>I'll be posting an updated version of this series today. > > But then early platform devices do not create a dev pointer. So you do > two initializations, eh? The early platform_device indeed has a struct device (it is a struct inside the platfor_device.) The difference is that the struct device has not been fully initialized (no device_add() has been called.) For our purposes here, that is perfectly OK, as all that matters is that there is a unique pointer to be used in the OPP layer. Kevin -- 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
