linux-toradex.git/Documentation/power, branch v3.10.78

PM / hibernate: Correct documentation

2013-05-13T23:58:43+00:00

Correct the meaning of PM_HIBERNATION_PREPARE in the docs.

References: http://lkml.kernel.org/r/20130512162717.GA6305@pd.tnic
Signed-off-by: Borislav Petkov 
Signed-off-by: Rafael J. Wysocki

PM / Documentation: remove inaccurate suspend/hibernate transition lantency statement

2013-05-13T23:46:50+00:00

The lantency of the transition from suspend and hibernate is
platform-dependent.  Thus we should not refer the lantency in the
documentation.

Signed-off-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki

PM: Documentation update for freeze state

2013-05-13T23:41:37+00:00

Signed-off-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki

PM / OPP: improve introductory documentation

2013-03-04T13:23:11+00:00

Make Operating Performance Points (OPP) library introductory chapter
a little more reader-friendly. Split the chapter into two sections,
highlight the definition with an example and minor rewording to be
verbose.

Reported-by: Linus Torvalds 
Signed-off-by: Nishanth Menon 
Reviewed-by: Randy Dunlap 
Signed-off-by: Rafael J. Wysocki

suspend: enable freeze timeout configuration through sys

2013-02-09T21:32:48+00:00

At present, the value of timeout for freezing is 20s, which is
meaningless in case that one thread is frozen with mutex locked
and another thread is trying to lock the mutex, as this time of
freezing will fail unavoidably.
And if there is no new wakeup event registered, the system will
waste at most 20s for such meaningless trying of freezing.

With this patch, the value of timeout can be configured to smaller
value, so such meaningless trying of freezing will be aborted in
earlier time, and later freezing can be also triggered in earlier
time. And more power will be saved.
In normal case on mobile phone, it costs real little time to freeze
processes. On some platform, it only costs about 20ms to freeze
user space processes and 10ms to freeze kernel freezable threads.

Signed-off-by: Liu Chuansheng 
Signed-off-by: Li Fei 
Signed-off-by: Rafael J. Wysocki

PM / Runtime: Add new helper function: pm_runtime_active()

2013-01-25T23:39:12+00:00

This boolean function simply returns whether or not the runtime
status of the device is 'active'. The typical scenario is driver
calls pm_runtime_get firstly, then check pm_runtime_active in
atomic environment.

Also add entry to Documentation/power/runtime.txt

Signed-off-by: Yanmin Zhang 
Signed-off-by: ShuoX Liu 
Signed-off-by: Rafael J. Wysocki

PM: Move disabling/enabling runtime PM to late suspend/early resume

2013-01-05T23:35:55+00:00

Currently, the PM core disables runtime PM for all devices right
after executing subsystem/driver .suspend() callbacks for them
and re-enables it right before executing subsystem/driver .resume()
callbacks for them.  This may lead to problems when there are
two devices such that the .suspend() callback executed for one of
them depends on runtime PM working for the other.  In that case,
if runtime PM has already been disabled for the second device,
the first one's .suspend() won't work correctly (and analogously
for resume).

To make those issues go away, make the PM core disable runtime PM
for devices right before executing subsystem/driver .suspend_late()
callbacks for them and enable runtime PM for them right after
executing subsystem/driver .resume_early() callbacks for them.  This
way the potential conflitcs between .suspend_late()/.resume_early()
and their runtime PM counterparts are still prevented from happening,
but the subtle ordering issues related to disabling/enabling runtime
PM for devices during system suspend/resume are much easier to avoid.

Reported-and-tested-by: Jan-Matthias Braun 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Ulf Hansson 
Reviewed-by: Kevin Hilman 
Cc: 3.4+

Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux

2012-12-12T06:15:57+00:00

The merge is merely to fix conflicts before sending a pull request.

Conflicts:
	drivers/power/ab8500_btemp.c
	drivers/power/ab8500_charger.c
	drivers/power/ab8500_fg.c
	drivers/power/abx500_chargalg.c
	drivers/power/max8925_power.c

Signed-off-by: Anton Vorontsov

power_supply: Add support for CHARGE_CONTROL_* attributes

2012-11-18T04:21:43+00:00

Add support for power supply attributes CHARGE_CONTROL_LIMIT
and CHARGE_CONTROL_LIMIT_MAX.

These new attributes will enable the user space to implement
custom charging algorithms based on platform state.

Signed-off-by: Ramakrishna Pallala 
Signed-off-by: Anton Vorontsov

PM / QoS: Introduce PM QoS device flags support

2012-10-22T23:09:12+00:00

Modify the device PM QoS core code to support PM QoS flags requests.

First, add a new field of type struct pm_qos_flags called "flags"
to struct dev_pm_qos for representing the list of PM QoS flags
requests for the given device.  Accordingly, add a new "type" field
to struct dev_pm_qos_request (along with an enum for representing
request types) and a new member called "flr" to its data union for
representig flags requests.

Second, modify dev_pm_qos_add_request(), dev_pm_qos_update_request(),
the internal routine apply_constraint() used by them and their
existing callers to cover flags requests as well as latency
requests.  In particular, dev_pm_qos_add_request() gets a new
argument called "type" for specifying the type of a request to be
added.

Finally, introduce two routines, __dev_pm_qos_flags() and
dev_pm_qos_flags(), allowing their callers to check which PM QoS
flags have been requested for the given device (the caller is
supposed to pass the mask of flags to check as the routine's
second argument and examine its return value for the result).

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Jean Pihet 
Reviewed-by: mark gross