linux-toradex.git/drivers/base/power/qos.c, branch v4.9.100

PM / QoS: Make it possible to expose device latency tolerance to userspace

2015-07-28T07:50:41+00:00

Typically when a device is created the bus core it belongs to (for example
PCI) does not know if the device supports things like latency tolerance.
This is left to the driver that binds to the device in question. However,
at that time the device has already been created and there is no way to set
its dev->power.set_latency_tolerance anymore.

So follow what has been done for other PM QoS attributes as well and allow
drivers to expose and hide latency tolerance from userspace, if the device
supports it.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Lee Jones

PM / QoS: Use lockdep asserts to find missing hold of power.lock

2015-01-23T21:31:08+00:00

Add lockdep asserts for holding the dev->power.lock to non-static
functions which require this. They could be used outside of the file so
asserts may help in detecting locking misuse.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Rafael J. Wysocki

PM: Drop CONFIG_PM_RUNTIME from the driver core

2014-12-03T23:46:58+00:00

After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM or even may be dropped entirely in some cases.

Replace CONFIG_PM_RUNTIME with CONFIG_PM in the PM core code.

Reviewed-by: Ulf Hansson 
Acked-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki

PM / QoS: Add type to dev_pm_qos_add_ancestor_request() arguments

2014-02-10T23:36:00+00:00

Rework dev_pm_qos_add_ancestor_request() so that device PM QoS type
is passed to it as the third argument and make it support the
DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type (in addition to
DEV_PM_QOS_RESUME_LATENCY).

That will allow the drivers of devices without latency tolerance
hardware support to use their ancestors having it as proxies for
their latency tolerance requirements.

Signed-off-by: Rafael J. Wysocki

PM / QoS: Introcuce latency tolerance device PM QoS type

2014-02-10T23:35:38+00:00

Add a new latency tolerance device PM QoS type to be use for
specifying active state (RPM_ACTIVE) memory access (DMA) latency
tolerance requirements for devices.  It may be used to prevent
hardware from choosing overly aggressive energy-saving operation
modes (causing too much latency to appear) for the whole platform.

This feature reqiures hardware support, so it only will be
available for devices having a new .set_latency_tolerance()
callback in struct dev_pm_info populated, in which case the
routine pointed to by it should implement whatever is necessary
to transfer the effective requirement value to the hardware.

Whenever the effective latency tolerance changes for the device,
its .set_latency_tolerance() callback will be executed and the
effective value will be passed to it.  If that value is negative,
which means that the list of latency tolerance requirements for
the device is empty, the callback is expected to switch the
underlying hardware latency tolerance control mechanism to an
autonomous mode if available.  If that value is PM_QOS_LATENCY_ANY,
in turn, and the hardware supports a special "no requirement"
setting, the callback is expected to use it.  That allows software
to prevent the hardware from automatically updating the device's
latency tolerance in response to its power state changes (e.g. during
transitions from D3cold to D0), which generally may be done in the
autonomous latency tolerance control mode.

If .set_latency_tolerance() is present for the device, a new
pm_qos_latency_tolerance_us attribute will be present in the
devivce's power directory in sysfs.  Then, user space can use
that attribute to specify its latency tolerance requirement for
the device, if any.  Writing "any" to it means "no requirement, but
do not let the hardware control latency tolerance" and writing
"auto" to it allows the hardware to be switched to the autonomous
mode if there are no other requirements from the kernel side in the
device's list.

This changeset includes a fix from Mika Westerberg.

Signed-off-by: Rafael J. Wysocki

PM / QoS: Add no_constraints_value field to struct pm_qos_constraints

2014-02-10T23:35:29+00:00

Add a new field, no_constraints_value, to struct pm_qos_constraints
representing a list of PM QoS constraint requests to be returned by
pm_qos_get_value() when that list of requests is empty.

That field will be equal to default_value for all of the existing
global PM QoS classes and for the resume latency device PM QoS type,
but it will be different from default_value for the new latency
tolerance device PM QoS type introduced by the next changeset.

Signed-off-by: Rafael J. Wysocki

PM / QoS: Rename device resume latency QoS items

2014-02-10T23:35:23+00:00

Rename symbols, variables, functions and structure fields related do
the resume latency device PM QoS type so that it is clear where they
belong (in particular, to avoid confusion with the latency tolerance
device PM QoS type introduced by a subsequent changeset).

Update the PM QoS documentation to better reflect its current state.

Signed-off-by: Rafael J. Wysocki

PM / QoS: Add dev_pm_qos_request tracepoints

2013-06-24T11:09:03+00:00

Adds tracepoints to dev_pm_qos_add_request, dev_pm_qos_update_request,
and dev_pm_qos_remove_request.  It's useful for checking device name,
dev_pm_qos_request_type, and value.

Signed-off-by: Sahara 
Signed-off-by: Rafael J. Wysocki

PM / QoS: Avoid possible deadlock related to sysfs access

2013-04-01T23:25:24+00:00

Commit b81ea1b (PM / QoS: Fix concurrency issues and memory leaks in
device PM QoS) put calls to pm_qos_sysfs_add_latency(),
pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and
pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which was a
mistake, because it may lead to deadlocks in some situations.
For example, if pm_qos_remote_wakeup_store() is run in parallel
with dev_pm_qos_constraints_destroy(), they may deadlock in the
following way:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: G        W
 -------------------------------------------------------
 trinity-child6/12371 is trying to acquire lock:
  (s_active#54){++++.+}, at: [] sysfs_addrm_finish+0x31/0x60

 but task is already holding lock:
  (dev_pm_qos_mtx){+.+.+.}, at: [] dev_pm_qos_constraints_destroy+0x23/0x250

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (dev_pm_qos_mtx){+.+.+.}:
        [] lock_acquire+0x1aa/0x240
        [] __mutex_lock_common+0x59/0x5e0
        [] mutex_lock_nested+0x3f/0x50
        [] dev_pm_qos_update_flags+0x3f/0xc0
        [] pm_qos_remote_wakeup_store+0x3f/0x70
        [] dev_attr_store+0x13/0x20
        [] sysfs_write_file+0xfa/0x150
        [] __kernel_write+0x81/0x150
        [] write_pipe_buf+0x4d/0x80
        [] splice_from_pipe_feed+0x7c/0x120
        [] __splice_from_pipe+0x45/0x80
        [] splice_from_pipe+0x4c/0x70
        [] default_file_splice_write+0x18/0x30
        [] do_splice_from+0x83/0xb0
        [] direct_splice_actor+0x1e/0x20
        [] splice_direct_to_actor+0xe7/0x200
        [] do_splice_direct+0x4c/0x70
        [] do_sendfile+0x169/0x300
        [] SyS_sendfile64+0x64/0xb0
        [] tracesys+0xe1/0xe6

 -> #0 (s_active#54){++++.+}:
        [] __lock_acquire+0x15bf/0x1e50
        [] lock_acquire+0x1aa/0x240
        [] sysfs_deactivate+0x122/0x1a0
        [] sysfs_addrm_finish+0x31/0x60
        [] sysfs_hash_and_remove+0x7f/0xb0
        [] sysfs_unmerge_group+0x51/0x70
        [] pm_qos_sysfs_remove_flags+0x14/0x20
        [] __dev_pm_qos_hide_flags+0x30/0x70
        [] dev_pm_qos_constraints_destroy+0x35/0x250
        [] dpm_sysfs_remove+0x11/0x50
        [] device_del+0x3f/0x1b0
        [] device_unregister+0x48/0x60
        [] usb_hub_remove_port_device+0x1c/0x20
        [] hub_disconnect+0xdd/0x160
        [] usb_unbind_interface+0x67/0x170
        [] __device_release_driver+0x87/0xe0
        [] device_release_driver+0x29/0x40
        [] bus_remove_device+0x148/0x160
        [] device_del+0x14f/0x1b0
        [] usb_disable_device+0xf9/0x280
        [] usb_set_configuration+0x268/0x840
        [] usb_remove_store+0x4c/0x80
        [] dev_attr_store+0x13/0x20
        [] sysfs_write_file+0xfa/0x150
        [] do_loop_readv_writev+0x4d/0x90
        [] do_readv_writev+0xf9/0x1e0
        [] vfs_writev+0x3a/0x60
        [] SyS_writev+0x50/0xd0
        [] tracesys+0xe1/0xe6

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(dev_pm_qos_mtx);
                                lock(s_active#54);
                                lock(dev_pm_qos_mtx);
   lock(s_active#54);

  *** DEADLOCK ***

To avoid that, remove the calls to functions mentioned above from
under dev_pm_qos_mtx and introduce a separate lock to prevent races
between functions that add or remove device PM QoS sysfs attributes
from happening.

Reported-by: Sasha Levin 
Signed-off-by: Rafael J. Wysocki

PM / QoS: Remove device PM QoS sysfs attributes at the right place

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

Device PM QoS sysfs attributes, if present during device removal,
are removed from within device_pm_remove(), which is too late,
since dpm_sysfs_remove() has already removed the whole attribute
group they belonged to.  However, moving the removal of those
attributes to dpm_sysfs_remove() alone is not sufficient, because
in theory they still can be re-added right after being removed by it
(the device's driver is still bound to it at that point).

For this reason, move the entire desctruction of device PM QoS
constraints to dpm_sysfs_remove() and make it prevent any new
constraints from being added after it has run.  Also, move the
initialization of the power.qos field in struct device to
device_pm_init_common() and drop the no longer needed
dev_pm_qos_constraints_init().

Reported-by: Sasha Levin 
Signed-off-by: Rafael J. Wysocki