All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@baylibre.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	"Nayak, Rajendra" <rnayak@codeaurora.org>,
	Georgi Djakov <georgi.djakov@linaro.org>,
	Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [Discussion] Performance levels of power domains
Date: Thu, 10 Nov 2016 11:14:43 -0800	[thread overview]
Message-ID: <m2y40rkuzg.fsf@baylibre.com> (raw)
In-Reply-To: <CAKohpo=D5KVNVEHqUd5SuEy0UNvTSqaUBd8MNuM8OTO=jjqKqw@mail.gmail.com> (Viresh Kumar's message of "Wed, 9 Nov 2016 17:16:16 +0530")

Viresh Kumar <viresh.kumar@linaro.org> writes:

> On 27 October 2016 at 15:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Wed, Oct 26, 2016 at 9:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>>
>>>> Hi Guys,
>>>>
>>>> I wanted to involve you guys to get a discussion going
>>>> for a problem we want to solve, and so this mail.
>>>>
>>>>
>>>> Platform details:
>>>>
>>>> Some of the Qualcom SoCs have the option to configure
>>>> the performance level of their Power Domains. The performance
>>>> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>>>>
>>>> Another M3 core handles the *real* voltage scaling based on the input
>>>> received (from software) in terms of these performance levels. The M3
>>>> core translates the levels into a range of voltages (corners) and selects
>>>> the right one by itself.
>>>>
>>>> Software needs to provide the performance level for the entire domain
>>>> to the M3 core and so software also needs to handle performance requests
>>>> from all the devices that lie in the domain X and find a Performance Level P,
>>>> which can satisfy all the devices (normally the highest requrested level).
>>>>
>>>>
>>>> Problem statement:
>>>>
>>>> As we aren't dealing with Voltages here, we can't really get the benefits
>>>> of the Regulators framework. The regulators are managed internally
>>>> by the M3 core. All we need is a way for software to comeout with inputs
>>>> for the M3 core.
>>>>
>>>> The OPP framework can be used to include performance levels for
>>>> each OPP (frequency) entry.
>>>>
>>>> But what framework can be used to select performance level of power
>>>> domains ?
>>>>
>>>> By name, power-domain or genpd looks to be the right choice, but until
>>>> now it is only managing power-on and power-off of devices and domains.
>>>
>>> genpd has also recently been extended to support multiple states, though
>>> those are still idle states, not active (performance) states.
>>>
>>>> Should we extend that (along with runtime PM), or do something else?
>>>
>>> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
>>> think extending genpd to handle performance states is a logical
>>> extension.  Otherwise, you will be (re)inventing something that looks an
>>> awful lot like genpd anyways.
>>
>> On the Intel side we also have a mechanism to tell the processor about
>> the power/performance preference and it would be good to have a common
>> way to do it on all platforms and genpd doesn't look like a
>> particularly good place for that.
>>
>>> The other related framework is per-device PM QoS which could be used to
>>> set constraints on specific devices, and the genpd governors would then
>>> be responsible for looking at the constraints and changing states as
>>> needed.
>>
>> Right.
>>
>> Let's talk about this at the LPC.
>
> Any updates from LPC on this ?

The short version: we agreed that extending genpd to support performance
states/levels is the right way to go.

Kevin

      reply	other threads:[~2016-11-10 19:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-26 10:52 [Discussion] Performance levels of power domains Viresh Kumar
2016-10-26 11:09 ` Sudeep Holla
2016-10-26 11:16   ` Viresh Kumar
2016-10-26 11:21     ` Sudeep Holla
2016-10-28  0:22       ` Stephen Boyd
2016-10-28  8:52         ` Sudeep Holla
2016-10-26 19:00 ` Kevin Hilman
2016-10-27  3:46   ` Viresh Kumar
2016-10-27  7:17     ` Vincent Guittot
2016-10-27  8:28       ` Viresh Kumar
2016-10-27 10:14     ` Rafael J. Wysocki
2016-10-27  7:13   ` Vincent Guittot
2016-10-27 10:11   ` Rafael J. Wysocki
2016-10-27 10:23     ` Viresh Kumar
2016-10-27 10:26       ` Rafael J. Wysocki
2016-10-27 11:46     ` Ulf Hansson
2016-10-28  4:02       ` Viresh Kumar
2016-10-27 13:12     ` Sudeep K N
2016-10-27 17:24     ` Kevin Hilman
2016-11-09 11:46     ` Viresh Kumar
2016-11-10 19:14       ` Kevin Hilman [this message]

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=m2y40rkuzg.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=georgi.djakov@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rnayak@codeaurora.org \
    --cc=sboyd@codeaurora.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /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.