On 06/20/2017 09:54 AM, Sudeep Holla wrote:

On 20/06/17 17:20, Florian Fainelli wrote:

quoted

On 06/20/2017 02:10 AM, Lorenzo Pieralisi wrote:

quoted

[+Sudeep]

On Mon, Jun 19, 2017 at 10:32:38AM -0700, Florian Fainelli wrote:

quoted

On 06/19/2017 05:24 AM, Mark Rutland wrote:

quoted

On Fri, Jun 16, 2017 at 05:07:40PM -0700, Florian Fainelli wrote:

quoted

Hi all,

Hi Florian,

quoted

This patch series makes ARM's fncpy() implementation more generic (dropping the
Thumb-specifics) and available in an asm-generic header file.

Tested on a Broadcom ARM64 STB platform with code that is written to SRAM.

Changes in v3 (thanks Doug!):
- correct include guard names in asm-generic/fncpy.h to __ASM_FNCPY_H
- utilize Kbuild to provide the fncpy.h header on ARM64

Changes in v2:
- leave the ARM implementation where it is
- make the generic truly generic (no)

This is helpful in making SoC-specific power management code become true drivers
that can be shared between different architectures.
Could you elaborate on what this is needed for?

Several uses cases come to mind:

- it could be used as a trampoline code prior to entering S2 for systems
that do not support PSCI 1.0

I think S2 here means PM_SUSPEND_MEM. It is very wrong to manage power
states through platform specific hooks on PSCI based systems, consider
upgrading to PSCI 1.0 please (or implement PSCI CPU_SUSPEND power
states that allow to achieve same power savings as PM_SUSPEND_MEM
by just entering suspend-to-idle).

S2 is PM_SUSPEND_STANDBY and S3 is PM_SUSPEND_MEM, at least that how I
read it. I would rather we update to PSCI 1.0 (at least) to properly
support SYSTEM_SUSPEND rather than retrofitting a system-wide suspend
state into CPU_SUSPEND since that seems wrong.

This has been discussed multiple times in the past. No one has come back
with strong reason to add that to the PSCI SYSTEM_SUSPEND API.

Care to explain the difference between PM_SUSPEND_STANDBY and S3 is
PM_SUSPEND_MEM on your platform. And why it can't be achieved with
suspend-to-idle ?

S2 preserves the ON/OFF island power and allows wake logic to wake the
system (infrared, GPIOs, Wake-on-LAN/WLAN, etc.) whereas S3 allows
powering off the ON/OFF island entirely, and allows for a lower power
consumption, with a subset of the wake peripherals to actually wake the
system. S5 is also implemented although its use case is narrower (soft-off).

The higher latency involved in S3 entry/exit is totally accepted due to
the higher power savings that it yields.

You can always report any issue with PSCI specification at
errata at arm.com as mentioned in the document.

I just did because there are a few other things missing.
-- 
Florian