Re: [linux-pm] Re: [RFC][PATCH -mm] PM: Introduce set_target method in pm_ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
On Sat, 2007-06-23 at 20:28 -0400, ext Alan Stern wrote:
> On Sun, 24 Jun 2007, Rafael J. Wysocki wrote:
> 
> > > Is this design okay with system states in which the CPU is able to
> run?
> > 
> > Do you mean the patch or the suggestions above?
> 
> The suggestions.
> 
> > > Right now the states we have are On, Standby, and Suspend, and the
> CPU
> > > runs only in the On state.  But on some platforms there could be
> > > multiple states in which the CPU is able to run, albeit with
> degraded 
> > > performance.
> > 
> > I wouldn't call those system sleep states.  For example, ACPI
> defines system
> > sleep states as the states in which no instructions are executed by
> any CPUs
> > and I think that's reasonable.
> > 
> > Moreover, the ACPI spec insists that transitions between different sleep
> > states should be made through the On state.
> 
> Okay.  But on non-ACPI systems, do we want to restrict the 
> /sys/power/state interface to sleep states?  How then should the user 
> tell the system to go to a low-performance run state?  Or should that 
> be handled automatically within the kernel?

That's how we do it since Nokia IT 770 where we have:
 
/sys/power/sleep_while_idle

and if that's set to 1 (default), then in the idle loop we try to hit
SoC retention.

Retention can be achieved if all the clocks have been released by their
respective users. If not all the clocks are free, the system oscillator
is not stopped and thereffore only some part will be in clock stop mode.
This, still, yelds significant power saving.

There is also an architecture specific (OMAP1 vs OMAP2) way to control
latency.

It's very rudimental and partially hackish: in OMAP2 it's mostly used to
workaround some missing wakeup dependencies (some are not provided by
the hw, some are not implemented properly by sw and should be fixed).

OMAP1: select ARM idle vs Big Sleep vs Deep Sleep

OMAP2: select ARM idle vs ARM retention, vs SoC retention

That's nice both from user's perspective (no need to worry about runtime
pm, it just works) and driver developer's perspective (if your driver is
for hw that has been properly wired, then using the clock fw interface
is enough).

So if you want to implement dependencies betweeen userspace and
kernelspace because your architecture has them builtin, it's ok, but
they should not be forced upon those arch that don't need them.


-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@xxxxxxxxx>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux