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 20:41:42 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Santosh Shilimkar <santosh.shilimkar@...com>
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

On Thursday, May 10, 2012, Santosh Shilimkar wrote:
> 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?

Nothing specific, really.  It can be any kind of I/O devices that happen
to be in the same power domain.  This includes USB, SDHI, MMCIF controllers
on the SoC I have in mind in particular.

> 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.

Depending on the definitions I guess.  How do you define a power domain and
a voltage domain?

> > 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.

Maybe it can, but I'm not so sure of that in general.

> We already do that for ARM SOCs.

Surely not all of them?  I know of a few at least where this isn't done.

> From the patch description it seems, they are general purpose
> peripherals.

Yes, they are.

> 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.

The system I have in mind is designed in such a way that there is a power
domain with three subdomains, one of which contains the CPU core and the
remaining two contain I/O devices of various kinds.  General purpose as well
as "core".

Thanks,
Rafael
--
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/