From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3 Date: Thu, 24 Jun 2010 11:09:45 -0700 Message-ID: <87eifwcnfa.fsf@deeprootsystems.com> References: <1276733833-18510-1-git-send-email-khilman@deeprootsystems.com> <1276733833-18510-6-git-send-email-khilman@deeprootsystems.com> <5A47E75E594F054BAF48C5E4FC4B92AB032366AB60@dbde02.ent.ti.com> <878w6524ae.fsf@deeprootsystems.com> <5A47E75E594F054BAF48C5E4FC4B92AB032366AC83@dbde02.ent.ti.com> <87wrtpwsjb.fsf@deeprootsystems.com> <5A47E75E594F054BAF48C5E4FC4B92AB032366AE4F@dbde02.ent.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-pv0-f174.google.com ([74.125.83.174]:42612 "EHLO mail-pv0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754467Ab0FXSJs (ORCPT ); Thu, 24 Jun 2010 14:09:48 -0400 Received: by pvg2 with SMTP id 2so472006pvg.19 for ; Thu, 24 Jun 2010 11:09:47 -0700 (PDT) In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB032366AE4F@dbde02.ent.ti.com> (Thara Gopinath's message of "Thu, 24 Jun 2010 11:53:42 +0530") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Gopinath, Thara" Cc: "linux-omap@vger.kernel.org" , "Menon, Nishanth" , "Cousson, Benoit" "Gopinath, Thara" writes: >>>-----Original Message----- >>>From: Kevin Hilman [mailto:khilman@deeprootsystems.com] >>>Sent: Wednesday, June 23, 2010 11:17 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" 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" 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 >>>>>>[...] >>>>>> >>>>>>>>>+ >>>>>>>>>+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. Agreed, I will drop those initcall change commits I made to the pm-sr branch. Kevin > 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