public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Linux PM mailing list <linux-pm@lists.linux-foundation.org>,
	linux-omap@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Paul Walmsley <paul@pwsan.com>,
	magnus.damm@gmail.com, Todd Poynor <toddpoynor@google.com>,
	Jean Pihet <j-pihet@ti.com>
Subject: Re: [PATCH 6/8] OMAP: PM CONSTRAINTS: implement the devices wake-up latency constraints
Date: Fri, 16 Sep 2011 08:56:49 -0700	[thread overview]
Message-ID: <87k498scou.fsf@ti.com> (raw)
In-Reply-To: <CAORVsuWH+MjOL-VYWZQt_Lxpp1=7Emw=ZXfeMCW8TofuX1u_vw@mail.gmail.com> (Jean Pihet's message of "Fri, 16 Sep 2011 17:43:10 +0200")

Jean Pihet <jean.pihet@newoldbits.com> writes:

> Kevin,
>
> On Fri, Sep 16, 2011 at 1:47 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Jean Pihet <jean.pihet@newoldbits.com> writes:
>>
>>> Implement the devices wake-up latency constraints using the global
>>> device PM QoS notification handler which applies the constraints to the
>>> underlying layer by calling the corresponding function at hwmod level.
>>>
>>> Note: the bus throughput function is implemented but currently is
>>> a no-op. A new PM QoS class for the bus throughput needs to be
>>> added.
>>>
>>> Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
>>> latency constraints on MPU, CORE and PER.
>>>
>>> Signed-off-by: Jean Pihet <j-pihet@ti.com>
>>
>> This patch does 2 things.
>>
>> 1) removes the MPU lat stuff from the OMAP PM layer (since it's now
>>   available in a generic form
>> 2) implements device wake-up latency constraints
>>
>> This should be broken up into two parts.
>>
>> Also, this patch seems to remove a bunch of stuff that was just added in
>> patch 2/8.  Probably best to create the new OMAP PM layer after remving
>> the unused stuff.
>>
>> It think the code using the new per-device PM QoS API should also live
>> outside the OMAP PM layer, since it's not related, and we want to get
>> rid of the OMAP PM layer eventually.
>>
>> Speaking of which..., the more I think about it, the more I think we
>> should take this opportunity to clean and/or remove the OMAP PM layer
>> completely.
>
>
> I agree completely, the OMAP PM 'plugin' layer is useless and anyway
> an empty implementation for now.

Great, let's wait for Paul's view on this since he's the maintainer of
the OMAP PM layer.

>> With your work, other than the no-op bus throughput API, it's basically
>> unused.  I think that rather than creating a new OMAP PM layer just to
>> have a a no-op bus throughput function here, I think it's time
>> to remove OMAP PM completely.
>
> Ok. The only useful code is to register a PM QoS notifier in order to
> apply the constraints to the power domains.
> Are you suggesting to move this code to e.g. pmxxx.c?

Yes, or simply pm-constraints.c since I guess it should be
SoC-independent.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-09-16 15:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-02 13:13 [PATCH 0/8] PM QoS: implement the OMAP low level constraints management code Jean Pihet
2011-09-02 13:13 ` [PATCH 1/8] OMAP: convert I2C driver to PM QoS for latency constraints Jean Pihet
2011-09-15 22:46   ` Kevin Hilman
2011-09-16 15:39     ` Jean Pihet
2011-09-16 16:06       ` Kevin Hilman
2011-09-02 13:13 ` [PATCH 2/8] OMAP: PM: create a PM layer plugin for per-device constraints Jean Pihet
2011-09-02 13:13 ` [PATCH 3/8] OMAP2+: powerdomain: control power domains next state Jean Pihet
2011-09-16 18:27   ` Kevin Hilman
2011-09-02 13:13 ` [PATCH 4/8] OMAP3: powerdomain data: add wake-up latency figures Jean Pihet
2011-09-02 13:13 ` [PATCH 5/8] OMAP2+: omap_hwmod: manage the wake-up latency constraints Jean Pihet
2011-09-02 13:13 ` [PATCH 6/8] OMAP: PM CONSTRAINTS: implement the devices " Jean Pihet
2011-09-15 23:47   ` Kevin Hilman
2011-09-16 15:43     ` Jean Pihet
2011-09-16 15:56       ` Kevin Hilman [this message]
2011-09-02 13:13 ` [PATCH 7/8] OMAP2+: cpuidle only influences the MPU state Jean Pihet
2011-09-02 13:13 ` [PATCH 8/8] OMAP3: update cpuidle latency and threshold figures Jean Pihet
2011-09-15  8:57 ` [PATCH 0/8] PM QoS: implement the OMAP low level constraints management code Jean Pihet

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=87k498scou.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=j-pihet@ti.com \
    --cc=jean.pihet@newoldbits.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=magnus.damm@gmail.com \
    --cc=paul@pwsan.com \
    --cc=rjw@sisk.pl \
    --cc=toddpoynor@google.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