All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@kernel.org>
To: Lina Iyer <lina.iyer@linaro.org>
Cc: ahaslam@baylibre.com, ulf.hansson@linaro.org,
	k.kozlowski.k@gmail.com, geert@linux-m68k.org, rjw@rjwysocki.net,
	bcousson@baylibre.com, linux-pm@vger.kernel.org,
	Axel Haslam <ahaslam+renesas@baylibre.com>
Subject: Re: [PATCH v7 2/5] PM / Domains: core changes for multiple states
Date: Fri, 08 May 2015 13:53:27 -0700	[thread overview]
Message-ID: <7ha8xehjug.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20150507155359.GA15980@linaro.org> (Lina Iyer's message of "Thu, 7 May 2015 09:53:59 -0600")

Lina Iyer <lina.iyer@linaro.org> writes:

> On Thu, Apr 30 2015 at 04:57 -0600, ahaslam@baylibre.com wrote:
>>From: Axel Haslam <ahaslam+renesas@baylibre.com>
>>
>>Add the core changes to be able to declare multiple states.
>>When trying to set a power domain to off, genpd will be able
>>to choose from an array of states declared by the platform.
>>
>>The power on and off latencies are now tied to a state.
>>
>>States should be declared in ascending order from shallowest
>>to deepest, deepest meaning the state which takes longer to
>>enter and exit.
>>
>>the power_off and power_on function can use the 'state_idx'
>>field of the generic_pm_domain structure, to distinguish between
>>the different states and act accordingly.
>>
>> - if the genpd is initially off, the user should set the state_idx
>>   field when registering the genpd.
>>
>> - if no states are passed to pm_genpd_init, a single OFF
>>   state with no latency is assumed.
>>
>>Example:
>>
>>static int pd1_power_on(struct generic_pm_domain *domain)
>>{
>>	/* domain->state_idx = state the domain is coming from */
>>}
>>
>>static int pd1_power_off(struct generic_pm_domain *domain)
>>{
>>	/* domain->state_idx = desired powered off state */
>>}
>>
>>const struct genpd_power_state pd_states[] = {
>>	{
>>		.name = "RET",
>>		.power_on_latency_ns = ON_LATENCY_FAST,
>>		.power_off_latency_ns = OFF_LATENCY_FAST,
>>	},
>>	{
>>		.name = "DEEP_RET",
>>		.power_on_latency_ns = ON_LATENCY_MED,
>>		.power_off_latency_ns = OFF_LATENCY_MED,
>>	},
>>	{
>>		.name = "OFF",
>>		.power_on_latency_ns = ON_LATENCY_SLOW,
>>		.power_off_latency_ns = OFF_LATENCY_SLOW,
>>	}
>>};
>>
>
> I am trying to use your patches in fashioning a genpd for the cpu
> domain.
>
> The cpus are part of a power domain that can be powered off when the
> cpus are powered off as part of the cpuidle. One of the biggest power
> savings comes from powering off the domain completely. However, powering
> off the domain involves flushing of caches (possibly) and turning off
> some regulators and peripheral hardware. The power benefit is only
> realized when the domain remains powered off for a certain period of
> time, otherwise the overhead of powering on/off would add up to the
> ineffeciency in the system.
>
> So a governor that determines the idle state of the domain has two
> things that needs to match, the time available to power off the domain
> (which we can get from timer wheel) and the other residency as dictated
> by the platform.
>
> I was wondering if we could match the idle state definition of the
> domain with that of the cpu, which has a precedence in the kernel. The
> idle state of the cpu [1] is a superset of the idle state definition you
> have above.  That way a shim layer could pick up domain idle states from
> DT and pass the states to pm_genpd_init(). The use of these values could
> depend on the genpd governor.

IMO, we need to keep the domain latency descriptions separate from the
the devices within those domains, which could be CPUs or any other form
of device.

It should be the job of the governor then to look at the domain latency
along with latencies of the other devices in the domain to make its
decision.

Kevin

  reply	other threads:[~2015-05-08 20:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-30 10:55 [PATCH v7 0/5] genpd multiple states v7 ahaslam
2015-04-30 10:55 ` [PATCH v7 1/5] PM / Domains: prepare for multiple states ahaslam
2015-04-30 15:29   ` Lina Iyer
2015-04-30 16:06     ` Axel Haslam
2015-05-01 16:31       ` Lina Iyer
2015-05-01 18:58       ` Geert Uytterhoeven
2015-05-08  0:36   ` Krzysztof Kozlowski
2015-05-11  8:23     ` Axel Haslam
2015-05-12 15:37   ` Lina Iyer
2015-05-12 16:26     ` Axel Haslam
2015-04-30 10:55 ` [PATCH v7 2/5] PM / Domains: core changes " ahaslam
2015-05-07 15:53   ` Lina Iyer
2015-05-08 20:53     ` Kevin Hilman [this message]
2015-05-08 22:31       ` Lina Iyer
2015-05-11 15:53         ` Axel Haslam
2015-05-11 16:50           ` Lina Iyer
2015-05-12 11:58             ` Axel Haslam
2015-05-12 15:29               ` Lina Iyer
2015-04-30 10:55 ` [PATCH v7 3/5] PM / Domains: make governor select deepest state ahaslam
2015-04-30 10:55 ` [PATCH v7 4/5] ARM: imx6: pm: declare pm domain latency on power_state struct ahaslam
2015-04-30 10:55 ` [PATCH v7 5/5] PM / Domains: remove old power on/off latencies ahaslam

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=7ha8xehjug.fsf@deeprootsystems.com \
    --to=khilman@kernel.org \
    --cc=ahaslam+renesas@baylibre.com \
    --cc=ahaslam@baylibre.com \
    --cc=bcousson@baylibre.com \
    --cc=geert@linux-m68k.org \
    --cc=k.kozlowski.k@gmail.com \
    --cc=lina.iyer@linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=ulf.hansson@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.