linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@linaro.org>
To: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: linux-pm@vger.kernel.org
Subject: Re: [PATCH][RFC] PM / Domains: Add on-off notifiers
Date: Mon, 18 Mar 2013 12:14:17 -0700	[thread overview]
Message-ID: <878v5kh65y.fsf@linaro.org> (raw)
In-Reply-To: <1363351143-28490-1-git-send-email-rickard.andersson@stericsson.com> (Rickard Andersson's message of "Fri, 15 Mar 2013 13:39:03 +0100")

Hi Rickard,

Rickard Andersson <rickard.andersson@stericsson.com> writes:

> Some drivers needs to restore their context directly
> when a power domain is activated. For example a driver
> handling system bus settings must be able to restore
> context before the bus is being used for the first time.
> Other examples could be clock settings hardware blocks and
> special debugging hardware blocks which should be restored
> as early as possible in order to be able to debug direcly
> from waking up. Typically these notifers are needed in
> systems with CPU coupled power domains. The notifiers
> are intended to be trigged by cpuidle driver or the
> suspend ops hooks.
>
> The drivers that needs to use these notifiers are
> some special cases. Most drivers should not use this
> method and instead control their context via the
> pm_runtime interface.
>
> Signed-off-by: Rickard Andersson <rickard.andersson@stericsson.com>

Some general comments.

First, I don't see where the notifiers are actually called in this
patch, so their intended use is not entirely clear.

Second, I'm a bit reluctant to see another layer of callbacks added to
the drivers.  I think using notifiers for this adds another level of
complexity to drivers that already have a pile of PM related callbacks
to manage.

IMO, it would be helpful to see an example driver using this feature,
and how it would interact with the drivers runtime PM callbacks.  For
example, I suspect that the the notifier callback would bascially be the
same as the runtime_resume callback, right?

Stated differently, at first glance, it seems the feature needed is
"runtime resume immidately after genpd power on".  Is that correct?

Also, the changelog implies that ordering may be crucial here (e.g bus
settings restored before bus is accessed), and using notifiers is not
going to give you that kind of ordering guarantee.

Kevin

  parent reply	other threads:[~2013-03-18 19:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-15 12:39 [PATCH][RFC] PM / Domains: Add on-off notifiers Rickard Andersson
2013-03-18 13:08 ` Ulf Hansson
2013-03-18 19:14 ` Kevin Hilman [this message]
2013-03-19 17:01   ` Rickard Andersson

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=878v5kh65y.fsf@linaro.org \
    --to=khilman@linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rickard.andersson@stericsson.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).