linux-kernel - Re: [RFC][PATCH 2/2] PM / Domains: Add preliminary cpuidle support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 May 2012 15:40:26 +0530
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Len Brown <lenb@...nel.org>,
	Colin Cross <ccross@...roid.com>,
	Kevin Hilman <khilman@...com>,
	Magnus Damm <magnus.damm@...il.com>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [RFC][PATCH 2/2] PM / Domains: Add preliminary cpuidle support

Rafael,

On Thursday 10 May 2012 03:13 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw@...k.pl>
> 
> On some systems there are CPU cores located in the same power
> domains as I/O devices.  Then, power can only be removed from the
> domain if all I/O devices in it are not in use and the CPU core
> is idle.  Add preliminary support for that to the generic PM domains
> framework.
> 
I am just curious to know, what kind of IO devices, you are
talking here? And also how those devices linked with CPU low power
states apart from being part of same power domain. And is it
the power domain or more of voltage domain, we are talking here.

> This assumes that there is only one CPU core in the system and it is
> supposed to be set up in the following way.
> 
> First, the platform is expected to provide a cpuidle driver with one
> extra state designated for the generic PM domains code to handle.
> This state should be initially disabled and its exit_latency value
> should be set to whatever time is needed to bring up the CPU core
> itself after restoring power to it, not including the domain's
> power on latency.  Its .enter() callback should point to a procedure
> that will save the CPU core's state as appropriate before power
> removal.  On success, it should return the same value as it has
> been passed as its third argument, but it shouldn't put the CPU
> core into a C-state.  If it is about to return the index of
> a different cpuidle state, however, it should make sure that the CPU
> be put into that state before it returns.
> 
> The remaining characteristics of the extra cpuidle state, referred to
> as the "domain" cpuidle state below, (e.g. power usage, target
> residency) should be populated in accordance with the properties of
> the hardware.
> 
> Next, the platform should execute genpd_attach_cpuidle() on the PM
> domain containing the CPU core.  That will cause the generic PM
> domains framework to treat that domain in a special way such that:
> 
>  * When all devices in the domain have been suspended and it is about
>    to be turned off, the states of the devices will be saved, but
>    power will not be removed from the domain.  Instead, the "domain"
>    cpuidle state will be enabled so that power can be removed from
>    the domain when the CPU core is idle and the state has been chosen
>    as the target by the cpuidle governor.  In that case, before
>    removing power from the domain, the framework will execute the
>    .enter() callback initially defined for the "domain" state.
> 
>  * When the first I/O device in the domain is resumed and
>    __pm_genpd_poweron(() is called for the first time after
>    power has been removed from the domain, the "domain" cpuidle
>    state will be disabled to avoid subsequent surprise power removals
>    via cpuidle.
> 

If these are CPU cluster/package specific IO's like interrupt
controller, cache controller, Coherency interconnect etc and
if the intention is to ensure that these devices context
is saved/restored in cpuidle entry/exit, it can be handled with
CPU PM notifiers. We already do that for ARM SOCs.

>From the patch description it seems, they are general purpose
peripherals. We had one thermal sensor on OMAP which
wrongly clocked from the CPU clock source and needed
some idle notifier infrastructure to prepare/resume
this device for idle entry/exit.

Regards
Santosh




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/