Exynos7 has core power down state where cores can be powered off independently.
This patch adds support for this state.
Signed-off-by: Chander Kashyap <redacted>
---
This patch has following dependencies:
- [PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
- [PATCH v9 0/8] ARM generic idle states
http://permalink.gmane.org/gmane.linux.power-management.general/49224
arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
status ? This is not a documented property. If you need it please explain
why, define its bindings and we can see how to accommodate it.
Thank you,
Lorenzo
While status is a relatively standard property, it's absence implies
everything is OK. There no need for it here as-is.
Additionally, the canonical value is "okay", not "enabled", so this
would fail were we to use of_device_is_available in the idle states
parsing.
status ? This is not a documented property. If you need it please explain
why, define its bindings and we can see how to accommodate it.
Do we expect that some idle states won't be available on some boards
built from the same platform?
Mark.
While status is a relatively standard property, it's absence implies
everything is OK. There no need for it here as-is.
Additionally, the canonical value is "okay", not "enabled", so this
would fail were we to use of_device_is_available in the idle states
parsing.
Good point. I still want it documented in the bindings, keeping in mind
your remark above.
quoted
status ? This is not a documented property. If you need it please explain
why, define its bindings and we can see how to accommodate it.
Do we expect that some idle states won't be available on some boards
built from the same platform?
I think it is something we should expect and be able to cope with that.
I will add status to idle-states bindings updates for this cycle and patch DT
parsing code accordingly.
Lorenzo
Hi Lorenzo,
On Wed, Oct 15, 2014 at 2:30 PM, Lorenzo Pieralisi
[off-list ref] wrote:
On Wed, Oct 15, 2014 at 07:35:20AM +0100, Chander Kashyap wrote:
quoted
Exynos7 has core power down state where cores can be powered off independently.
This patch adds support for this state.
Please tell us more about the idle-state values you are adding, in particular
entry, exit latencies and min-residency values.
Entry latency: This value is calculated as follows:
On entry to arm64_enter_idle_state:
timestamp1 = ktimeget();
after returning from cpu_suspend()
timestamp2 = ktimeget();
latency = timestamp2-timestamp1;
Cpu is not allowed to enter core powerdown by skipping wfi instruction at end.
Hence calculated time contains entry time + failure exit time.
Regarding
exit-latency and target-residency time, got these values from HW team.
I am using these as initial values and I will be working on optimizing
these values with further experiments.
If you could suggest any formal method of deriving these values, i can
try those methods as well.
From: Lorenzo Pieralisi <hidden> Date: 2014-10-21 16:33:46
On Fri, Oct 17, 2014 at 10:43:59AM +0100, Chander Kashyap wrote:
Hi Lorenzo,
On Wed, Oct 15, 2014 at 2:30 PM, Lorenzo Pieralisi
[off-list ref] wrote:
quoted
On Wed, Oct 15, 2014 at 07:35:20AM +0100, Chander Kashyap wrote:
quoted
Exynos7 has core power down state where cores can be powered off independently.
This patch adds support for this state.
Please tell us more about the idle-state values you are adding, in particular
entry, exit latencies and min-residency values.
Entry latency: This value is calculated as follows:
On entry to arm64_enter_idle_state:
timestamp1 = ktimeget();
after returning from cpu_suspend()
timestamp2 = ktimeget();
latency = timestamp2-timestamp1;
Cpu is not allowed to enter core powerdown by skipping wfi instruction at end.
This may not be the worst case (because the worst case depends on the state
of the cache in the core unless the latency is power down command dominated,
so at the cost of being pedantic, please make sure that's what you are
measuring and document it in the commit log).
Hence calculated time contains entry time + failure exit time.
Regarding
exit-latency and target-residency time, got these values from HW team.
I am using these as initial values and I will be working on optimizing
these values with further experiments.
If you could suggest any formal method of deriving these values, i can
try those methods as well.
Well, you have to set the core/cluster in worst case scenario and
compute the break-even residency against wfi (since you have two
states); it certainly has a dependency on PSCI implementation too among
other things.
exit-latency should come from HW design even though there is a cache
refill factor to be considered too and should be factored in.
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Sorry for very late response. As i was on vacation so couldn?t reply.
On Tue, Oct 21, 2014 at 10:03 PM, Lorenzo Pieralisi
[off-list ref] wrote:
On Fri, Oct 17, 2014 at 10:43:59AM +0100, Chander Kashyap wrote:
quoted
Hi Lorenzo,
On Wed, Oct 15, 2014 at 2:30 PM, Lorenzo Pieralisi
[off-list ref] wrote:
quoted
On Wed, Oct 15, 2014 at 07:35:20AM +0100, Chander Kashyap wrote:
quoted
Exynos7 has core power down state where cores can be powered off independently.
This patch adds support for this state.
Please tell us more about the idle-state values you are adding, in particular
entry, exit latencies and min-residency values.
Entry latency: This value is calculated as follows:
On entry to arm64_enter_idle_state:
timestamp1 = ktimeget();
after returning from cpu_suspend()
timestamp2 = ktimeget();
latency = timestamp2-timestamp1;
Cpu is not allowed to enter core powerdown by skipping wfi instruction at end.
This may not be the worst case (because the worst case depends on the state
of the cache in the core unless the latency is power down command dominated,
so at the cost of being pedantic, please make sure that's what you are
measuring and document it in the commit log).
If i understood correctly you are referring to cache flush time.
The measured entry latency time is averaged time for 100000
transactions with varying load.
I will document entry latency calculation in the commit message.
quoted
Hence calculated time contains entry time + failure exit time.
Regarding
exit-latency and target-residency time, got these values from HW team.
I am using these as initial values and I will be working on optimizing
these values with further experiments.
If you could suggest any formal method of deriving these values, i can
try those methods as well.
Well, you have to set the core/cluster in worst case scenario and
compute the break-even residency against wfi (since you have two
states); it certainly has a dependency on PSCI implementation too among
other things.
exit-latency should come from HW design even though there is a cache
refill factor to be considered too and should be factored in.
Exit and target residency are provided by HW team.
I will post the V3 with changed commit message.
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html