On Wed, Aug 08, 2018 at 12:02:48PM -0600, Lina Iyer wrote:

On Wed, Aug 08 2018 at 04:56 -0600, Lorenzo Pieralisi wrote:

quoted

On Mon, Aug 06, 2018 at 11:37:55AM +0200, Rafael J. Wysocki wrote:

quoted

On Fri, Aug 3, 2018 at 1:42 PM, Ulf Hansson [off-list ref] wrote:

quoted

[...]

quoted

quoted

Assuming that I have got that right, there are concerns, mostly regarding
patch [07/26], but I will reply to that directly.

Well, I haven't got that right, so never mind.

There are a few minor things to address, but apart from that the general
genpd patches look ready.

Alright, thanks!

I will re-spin the series and post a new version once 4.19 rc1 is out.
Hopefully we can queue it up early in next cycle to get it tested in
next for a while.

quoted

quoted

The $subject patch is fine by me by itself, but it obviously depends on the
previous ones.  Patches [01-02/26] are fine too, but they don't seem to be
particularly useful without the rest of the series.

As far as patches [10-26/26] go, I'd like to see some review comments and/or
tags from the people with vested interest in there, in particular from Daniel
on patch [12/26] and from Sudeep on the PSCI ones.

But this still holds.

Actually, patch 10 and patch11 is ready to go as well. I ping Daniel
on patch 12.

In regards to the rest of the series, some of the PSCI/ARM changes
have been reviewed by Mark Rutland, however several changes have not
been acked.

On the other hand, one can also interpret the long silence in regards
to PSCI/ARM changes as they are good to go. :-)

Well, in that case giving an ACK to them should not be an issue for
the people with a vested interest I suppose.

Apologies to everyone for the delay in replying.

Side note: cpu_pm_enter()/exit() are also called through syscore ops in
s2RAM/IDLE, you know that but I just wanted to mention it to compound
the discussion.

As for PSCI patches I do not personally think PSCI OSI enablement is
beneficial (and my position has always been the same since PSCI OSI was
added to the specification, I am not even talking about this patchset)
and Arm Trusted Firmware does not currently support it for the same
reason.

We (if Mark and Sudeep agree) will enable PSCI OSI if and when we have a
definitive and constructive answer to *why* we have to do that that is
not a dogmatic "the kernel knows better" but rather a comprehensive
power benchmark evaluation - I thought that was the agreement reached
at OSPM but apparently I was mistaken.

I will not speak to any comparison of benchmarks between OSI and PC.
AFAIK, there are no platforms supporting both.

PSCI specifications, 5.20.1:

"The platform will boot in platform-coordinated mode."

So all platforms implementing OSI have to support both.

But, the OSI feature is critical for QCOM mobile platforms. The
last man activities during cpuidle save quite a lot of power.

What I expressed above was that, in PSCI based systems (OSI or PC
alike), it is up to firmware/hardware to detect "the last man" not
the kernel.

I need to understand what you mean by "last man activities" to
provide feedback here.

Powering off the clocks, busses, regulators and even the oscillator is
very important to have a reasonable battery life when using the phone.
Platform coordinated approach falls quite short of the needs of a
powerful processor with a desired battery efficiency.

I am sorry but if you want us to merge PSCI patches in this series you
will have to back the claim above with a detailed technical explanation
of *why* platform-coordination falls short of QCOM (or whoever else)
needs wrt PSCI OSI.

Thanks,
Lorenzo