OMAP PM late init with DT blob

OMAP PM late init with DT blob

[Bedia, Vaibhav]

Hi,

I am looking at adding PM support for AM335x based on l-o/master.
arch/arm/mach-omap2/pm.c has the following comment:

/*
 * In the case of DT, the PMIC and SR initialization will be done using
 * a completely different mechanism.
 * Disable this part if a DT blob is available.
 */
if (of_have_populated_dt())
        return 0;

Basic DT support for AM335x is already in mainline so this check causes
various PM related inits and also the registration of the suspend ops to be
skipped.

I tried searching the list archives for any discussion on this but could not
find anything. Can someone shed some light on the how the device tree is to
be used for PMIC and SR initialization. 

Any objections to moving the suspend ops registration before the DT blob check?

Regards,
Vaibhav B.

Re: OMAP PM late init with DT blob

[Paul Walmsley]

On Tue, 17 Jul 2012, Bedia, Vaibhav wrote:

> I am looking at adding PM support for AM335x based on l-o/master.
> arch/arm/mach-omap2/pm.c has the following comment:
> 
> /*
>  * In the case of DT, the PMIC and SR initialization will be done using
>  * a completely different mechanism.
>  * Disable this part if a DT blob is available.
>  */
> if (of_have_populated_dt())
>         return 0;
> 
> Basic DT support for AM335x is already in mainline so this check causes
> various PM related inits and also the registration of the suspend ops to be
> skipped.
> 
> I tried searching the list archives for any discussion on this but could not
> find anything. Can someone shed some light on the how the device tree is to
> be used for PMIC and SR initialization. 
> 
> Any objections to moving the suspend ops registration before the DT blob check?

Moving the registration makes sense to me, based on a quick look.

IMHO, a better approach for this code would be to reverse the sense of 
that of_have_populated_dt() test, and specifically wrap the parts that are 
going to be changed by DT.  The rationale here is that only certain steps 
need to be skipped, so those should probably be skipped explicitly rather 
than skipping the whole function.


- Paul

RE: OMAP PM late init with DT blob

[Bedia, Vaibhav]

Hi Paul,

On Wed, Jul 18, 2012 at 02:03:04, Paul Walmsley wrote:
> On Tue, 17 Jul 2012, Bedia, Vaibhav wrote:
> 
> > I am looking at adding PM support for AM335x based on l-o/master.
> > arch/arm/mach-omap2/pm.c has the following comment:
> > 
> > /*
> >  * In the case of DT, the PMIC and SR initialization will be done using
> >  * a completely different mechanism.
> >  * Disable this part if a DT blob is available.
> >  */
> > if (of_have_populated_dt())
> >         return 0;
> > 
> > Basic DT support for AM335x is already in mainline so this check causes
> > various PM related inits and also the registration of the suspend ops to be
> > skipped.
> > 
> > I tried searching the list archives for any discussion on this but could not
> > find anything. Can someone shed some light on the how the device tree is to
> > be used for PMIC and SR initialization. 
> > 
> > Any objections to moving the suspend ops registration before the DT blob check?
> 
> Moving the registration makes sense to me, based on a quick look.
> 
> IMHO, a better approach for this code would be to reverse the sense of 
> that of_have_populated_dt() test, and specifically wrap the parts that are 
> going to be changed by DT.  The rationale here is that only certain steps 
> need to be skipped, so those should probably be skipped explicitly rather 
> than skipping the whole function.
> 

I checked the different inits which get skipped right now. I think _init_voltages()
should not really be dependent on the DT check to cover the cases wherein the voltages
are controlled using a regular regulator driver. However right now I don't know what
approach to take here. For now I have sent an RFC patch [1] with just the movement of
suspend ops.

Regards,
Vaibhav B.

[1] http://marc.info/?l=linux-omap&m=134260813520149&w=2 

RE: OMAP PM late init with DT blob

[Paul Walmsley]

On Wed, 18 Jul 2012, Bedia, Vaibhav wrote:

> I checked the different inits which get skipped right now. I think _init_voltages()
> should not really be dependent on the DT check to cover the cases wherein the voltages
> are controlled using a regular regulator driver. However right now I don't know what
> approach to take here. For now I have sent an RFC patch [1] with just the movement of
> suspend ops.

That seems reasonable based on a quick glance.  Why not update your patch 
to just keep that code where it is and wrap the the pmic and voltage late 
init in that DT test?


- Paul

RE: OMAP PM late init with DT blob

[Bedia, Vaibhav]

On Wed, Jul 18, 2012 at 21:52:41, Paul Walmsley wrote:
> On Wed, 18 Jul 2012, Bedia, Vaibhav wrote:
> 
> > I checked the different inits which get skipped right now. I think _init_voltages()
> > should not really be dependent on the DT check to cover the cases wherein the voltages
> > are controlled using a regular regulator driver. However right now I don't know what
> > approach to take here. For now I have sent an RFC patch [1] with just the movement of
> > suspend ops.
> 
> That seems reasonable based on a quick glance.  Why not update your patch 
> to just keep that code where it is and wrap the the pmic and voltage late 
> init in that DT test?
> 
Done. I had somehow messed up Kevin's address also :\ Fixed now.

Regards,
Vaibhav