>>-----Original Message----- >>From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] >>Sent: Wednesday, June 23, 2010 11:17 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: 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. Ok. I also think that the initcalls for voltage and sr_device should be moved back to the original. The order of initialization should be as follows. 1. Build the generic omap devices (like mpu, l3, dsp etc) (part of init_common_hw) 2. Initialize the opp structures. (part of init_common_hw) 3. Intialize the voltage layer. (arch_initcall) 4. Initialize the smartreflex device layer(subsys initcall) 5. Initialize the smartreflex srive.(late initcall) 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
