All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Walmsley <paul@pwsan.com>
To: "Bedia, Vaibhav" <vaibhav.bedia@ti.com>
Cc: "Cousson, Benoit" <b-cousson@ti.com>,
	"Hilman, Kevin" <khilman@ti.com>,
	linux-omap <linux-omap@vger.kernel.org>
Subject: Re: OMAP PM late init with DT blob
Date: Tue, 17 Jul 2012 14:33:04 -0600 (MDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1207171430430.28834@utopia.booyaka.com> (raw)
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EB110DA@DBDE01.ent.ti.com>

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

  reply	other threads:[~2012-07-17 20:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-17 11:24 OMAP PM late init with DT blob Bedia, Vaibhav
2012-07-17 20:33 ` Paul Walmsley [this message]
2012-07-18 11:03   ` Bedia, Vaibhav
2012-07-18 16:22     ` Paul Walmsley
2012-07-19 12:26       ` Bedia, Vaibhav

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1207171430430.28834@utopia.booyaka.com \
    --to=paul@pwsan.com \
    --cc=b-cousson@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=vaibhav.bedia@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.