Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
"Gopinath, Thara" writes:
>>>-Original Message-
>>>From: Kevin Hilman [mailto:khil...@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:khil...@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:khil...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@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:khil...@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:khil...@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.
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
"Gopinath, Thara" writes:
>>>-Original Message-
>>>From: Kevin Hilman [mailto:khil...@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:khil...@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.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@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:khil...@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?
Regards
Thara
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
"Gopinath, Thara" writes:
>>>-Original Message-
>>>From: Kevin Hilman [mailto:khil...@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.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 05/12] OMAP: create omap_devices for MPU, DSP, L3
>>-Original Message-
>>From: Kevin Hilman [mailto:khil...@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
>>---
>> arch/arm/mach-omap2/devices.c|2 +
>> arch/arm/mach-omap2/io.c | 68
>> --
>> arch/arm/plat-omap/include/plat/common.h |4 ++
>> 3 files changed, 70 insertions(+), 4 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
>>index 03e6c9e..62920ac 100644
>>--- a/arch/arm/mach-omap2/devices.c
>>+++ b/arch/arm/mach-omap2/devices.c
>>@@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>>+#include
>>
>> #include
>> #include
>>@@ -29,6 +30,7 @@
>> #include
>> #include
>> #include
>>+#include
>>
>> #include "mux.h"
>>
>>diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
>>index 78d37c0..12a2836 100644
>>--- a/arch/arm/mach-omap2/io.c
>>+++ b/arch/arm/mach-omap2/io.c
>>@@ -44,7 +44,7 @@
>>
>> #include
>> #include "clockdomains.h"
>>-#include
>>+#include
>>
>> #include "omap3-opp.h"
>> /*
>>@@ -311,12 +311,71 @@ static int __init _omap2_init_reprogram_sdrc(void)
>> return v;
>> }
>>
>>-void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>>- struct omap_sdrc_params *sdrc_cs1)
>>+static struct omap_device_pm_latency *pm_lats;
>>+
>>+static struct device *mpu_dev; /* FIXME: needs clean SMP support */
>>+static struct device *dsp_dev;
>>+static struct device *l3_dev;
>>+
>>+struct device *omap_get_mpu_device(void)
>>+{
>>+ WARN_ON_ONCE(!mpu_dev);
>>+ return mpu_dev;
>>+}
>>+
>>+struct device *omap_get_dsp_device(void)
>>+{
>>+ WARN_ON_ONCE(!dsp_dev);
>>+ return dsp_dev;
>>+}
>>+
>>+struct device *omap_get_l3_device(void)
>> {
>>+ WARN_ON_ONCE(!l3_dev);
>>+ return l3_dev;
>>+}
>>+
>>+static int _init_omap_device(struct omap_hwmod *oh, void *user)
>>+{
>>+ struct omap_device *od;
>>+ const char *name = oh->name;
>>+ struct device **new_dev = (struct device **)user;
>>+
>>+ od = omap_device_build(name, 0, oh, NULL, 0, pm_lats, 0, false);
>>+ if (WARN(IS_ERR(od), "Could not build omap_device for %s\n", name))
>>+ return -ENODEV;
>>+
>>+ *new_dev = &od->pdev.dev;
>>+
>>+ return 0;
>>+}
>>+
>>+/*
>>+ * Build omap_devices for processors and bus.
>>+ */
>>+static void omap_init_processor_devices(void)
>>+{
>>+ omap_hwmod_for_each_by_class("mpu", _init_omap_device, &mpu_dev);
>>+ omap_hwmod_for_each_by_class("dsp", _init_omap_device, &dsp_dev);
>>+ omap_hwmod_for_each_by_class("l3", _init_omap_device, &l3_dev);
>>+}
>>+
>>+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.
Regards
Thara
>>+
>>+void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
>>+ struct omap_sdrc_params *sdrc_cs1)
>>+{
>> pwrdm_init(powerdomains_omap);
>> clkdm_init(clockdomains_omap, clkdm_autodeps);
>> if (cpu_is_omap242x())
>>@@ -325,6 +384,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
>>*sdrc_cs0,
>> omap2430_hwmod_init();
>> else if (cpu_is_omap34xx())
>> omap3xxx_hwmod_init();
>>+
>> omap2_mux_init();
>> omap_pm_if_early_init();
>>
>>@@ -342,7 +402,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params
>>*sdrc_cs0,
>> omap_serial_early_init();
>> if (cpu_is_omap2
