Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3

[Kevin Hilman <khilman@deeprootsystems.com>]

"Gopinath, Thara" <thara@ti.com> writes:

>>>-----Original Message-----
>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>Sent: Wednesday, June 23, 2010 8:19 PM
>>>To: Gopinath, Thara
>>>Cc: linux-omap@vger.kernel.org; Menon, Nishanth; Cousson, Benoit
>>>Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>>
>>>"Gopinath, Thara" <thara@ti.com> writes:
>>>
>>>>>>-----Original Message-----
>>>>>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
>>>>>>Sent: Thursday, June 17, 2010 5:47 AM
>>>>>>To: linux-omap@vger.kernel.org
>>>>>>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@deeprootsystems.com>
>>>[...]
>>>
>>>>>>+
>>>>>>+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