Revision tags: v5.10, v5.8.17 |
|
#
d6e36668 |
| 21-Oct-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Drop pm_runtime_clean_up_links()
After commit d12544fb2aa9 ("PM: runtime: Remove link state checks in rpm_get/put_supplier()") nothing prevents the consumer device's runtime PM from acq
PM: runtime: Drop pm_runtime_clean_up_links()
After commit d12544fb2aa9 ("PM: runtime: Remove link state checks in rpm_get/put_supplier()") nothing prevents the consumer device's runtime PM from acquiring additional references to the supplier device after pm_runtime_clean_up_links() has run (or even while it is running), so calling this function from __device_release_driver() may be pointless (or even harmful).
Moreover, it ignores stateless device links, so the runtime PM handling of managed and stateless device links is inconsistent because of it, so better get rid of it entirely.
Fixes: d12544fb2aa9 ("PM: runtime: Remove link state checks in rpm_get/put_supplier()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Tested-by: Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e0e398e2 |
| 21-Oct-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Drop runtime PM references to supplier on link removal
While removing a device link, drop the supplier device's runtime PM usage counter as many times as needed to drop all of the runti
PM: runtime: Drop runtime PM references to supplier on link removal
While removing a device link, drop the supplier device's runtime PM usage counter as many times as needed to drop all of the runtime PM references to it from the consumer in addition to dropping the consumer's link count.
Fixes: baa8809f6097 ("PM / runtime: Optimize the use of device links") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Tested-by: Xiang Chen <chenxiang66@hisilicon.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11 |
|
#
d12544fb |
| 22-Sep-2020 |
Xiang Chen <chenxiang66@hisilicon.com> |
PM: runtime: Remove link state checks in rpm_get/put_supplier()
To support runtime PM for hisi SAS driver (the driver is in directory drivers/scsi/hisi_sas), we add device link between scsi_device->
PM: runtime: Remove link state checks in rpm_get/put_supplier()
To support runtime PM for hisi SAS driver (the driver is in directory drivers/scsi/hisi_sas), we add device link between scsi_device->sdev_gendev (consumer device) and hisi_hba->dev(supplier device) with flags DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE.
After runtime suspended consumers and supplier, unload the dirver which causes a hung.
We found that it called function device_release_driver_internal() to release the supplier device (hisi_hba->dev), as the device link was busy, it set the device link state to DL_STATE_SUPPLIER_UNBIND, and then it called device_release_driver_internal() to release the consumer device (scsi_device->sdev_gendev).
Then it would try to call pm_runtime_get_sync() to resume the consumer device, but because consumer-supplier relation existed, it would try to resume the supplier first, but as the link state was already DL_STATE_SUPPLIER_UNBIND, so it skipped resuming the supplier and only resumed the consumer which hanged (it sends IOs to resume scsi_device while the SAS controller is suspended).
Simple flow is as follows:
device_release_driver_internal -> (supplier device) if device_links_busy -> device_links_unbind_consumers -> ... WRITE_ONCE(link->status, DL_STATE_SUPPLIER_UNBIND) device_release_driver_internal (consumer device) pm_runtime_get_sync -> (consumer device) ... __rpm_callback -> rpm_get_suppliers -> if link->state == DL_STATE_SUPPLIER_UNBIND -> skip the action of resuming the supplier ... pm_runtime_clean_up_links ...
Correct suspend/resume ordering between a supplier device and its consumer devices (resume the supplier device before resuming consumer devices, and suspend consumer devices before suspending the supplier device) should be guaranteed by runtime PM, but the state checks in rpm_get_supplier() and rpm_put_supplier() break this rule, so remove them.
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> [ rjw: Subject and changelog edits ] Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8 |
|
#
0abf803e |
| 31-Jul-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Improve kerneldoc of pm_runtime_get_if_active()
The kerneldoc comment of pm_runtime_get_if_active() doesn't list the second argument of the function properly, so fix that and while at i
PM: runtime: Improve kerneldoc of pm_runtime_get_if_active()
The kerneldoc comment of pm_runtime_get_if_active() doesn't list the second argument of the function properly, so fix that and while at it clarify that comment somewhat and add some markup to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
show more ...
|
Revision tags: v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
3618bbaa |
| 22-May-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
PM: runtime: Make clear what we do when conditions are wrong in rpm_suspend()
rpm_suspend() simple bails out when conditions are wrong. But this is not immediately obvious from the code. Make it cl
PM: runtime: Make clear what we do when conditions are wrong in rpm_suspend()
rpm_suspend() simple bails out when conditions are wrong. But this is not immediately obvious from the code. Make it clear what we do when conditions are wrong in rpm_suspend().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23 |
|
#
c111566b |
| 25-Feb-2020 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
PM: runtime: Add pm_runtime_get_if_active()
pm_runtime_get_if_in_use() bumps up the PM-runtime usage count if it is not equal to zero and the device's PM-runtime status is 'active'. This works for d
PM: runtime: Add pm_runtime_get_if_active()
pm_runtime_get_if_in_use() bumps up the PM-runtime usage count if it is not equal to zero and the device's PM-runtime status is 'active'. This works for drivers that do not use autoidle, but for those that do, the function returns zero even when the device is active.
In order to maintain sane device state while the device is powered on in the hope that it'll be needed, pm_runtime_get_if_active(dev, true) returns a positive value if the device's PM-runtime status is 'active' when it is called, in which case it also increments the device's usage count.
If the second argument of pm_runtime_get_if_active() is 'false', the function behaves just like pm_runtime_get_if_in_use(), so redefine the latter as a wrapper around the former.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8 |
|
#
d2292906 |
| 04-Jan-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
PM-runtime: add tracepoints for usage_count changes
Add tracepoints to remaining places where device's power.usage_count is changed.
This helps debugging where and why autosuspend is prevented.
Si
PM-runtime: add tracepoints for usage_count changes
Add tracepoints to remaining places where device's power.usage_count is changed.
This helps debugging where and why autosuspend is prevented.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2 |
|
#
c2fa1e1b |
| 16-Jul-2019 |
Joel Fernandes (Google) <joel@joelfernandes.org> |
driver/core: Convert to use built-in RCU list checking
This commit applies the consolidated hlist_for_each_entry_rcu() support for lockdep conditions.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoun
driver/core: Convert to use built-in RCU list checking
This commit applies the consolidated hlist_for_each_entry_rcu() support for lockdep conditions.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
show more ...
|
#
515db266 |
| 16-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
driver core: Remove device link creation limitation
If device_link_add() is called for a consumer/supplier pair with an existing device link between them and the existing link's type is not in agree
driver core: Remove device link creation limitation
If device_link_add() is called for a consumer/supplier pair with an existing device link between them and the existing link's type is not in agreement with the flags passed to that function by its caller, NULL will be returned. That is seriously inconvenient, because it forces the callers of device_link_add() to worry about what others may or may not do even if that is not relevant to them for any other reasons.
It turns out, however, that this limitation can be made go away relatively easily.
The underlying observation is that if DL_FLAG_STATELESS has been passed to device_link_add() in flags for the given consumer/supplier pair at least once, calling either device_link_del() or device_link_remove() to release the link returned by it should work, but there are no other requirements associated with that flag. In turn, if at least one of the callers of device_link_add() for the given consumer/supplier pair has not passed DL_FLAG_STATELESS to it in flags, the driver core should track the status of the link and act on it as appropriate (ie. the link should be treated as "managed"). This means that DL_FLAG_STATELESS needs to be set for managed device links and it should be valid to call device_link_del() or device_link_remove() to drop references to them in certain sutiations.
To allow that to happen, introduce a new (internal) device link flag called DL_FLAG_MANAGED and make device_link_add() set it automatically whenever DL_FLAG_STATELESS is not passed to it. Also make it take additional references to existing device links that were previously stateless (that is, with DL_FLAG_STATELESS set and DL_FLAG_MANAGED unset) and will need to be managed going forward and initialize their status (which has been DL_STATE_NONE so far).
Accordingly, when a managed device link is dropped automatically by the driver core, make it clear DL_FLAG_MANAGED, reset the link's status back to DL_STATE_NONE and drop the reference to it associated with DL_FLAG_MANAGED instead of just deleting it right away (to allow it to stay around in case it still needs to be released explicitly by someone).
With that, since setting DL_FLAG_STATELESS doesn't mean that the device link in question is not managed any more, replace all of the status-tracking checks against DL_FLAG_STATELESS with analogous checks against DL_FLAG_MANAGED and update the documentation to reflect these changes.
While at it, make device_link_add() reject flags that it does not recognize, including DL_FLAG_MANAGED.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Review-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/2305283.AStDPdUUnE@kreacher Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.2.1, v5.2 |
|
#
8262331e |
| 04-Jul-2019 |
Viresh Kumar <viresh.kumar@linaro.org> |
PM / QOS: Rename __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value()
dev_pm_qos_read_value() will soon need to support more constraint types (min/max frequency) and will have another argument
PM / QOS: Rename __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value()
dev_pm_qos_read_value() will soon need to support more constraint types (min/max frequency) and will have another argument to it, i.e. type of the constraint. While that is fine for the existing users of dev_pm_qos_read_value(), but not that optimal for the callers of __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value() as all the callers of these two routines are only looking for resume latency constraint.
Lets make these two routines care only about the resume latency constraint and rename them to __dev_pm_qos_resume_latency() and dev_pm_qos_raw_resume_latency().
Suggested-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6 |
|
#
5de363b6 |
| 02-Apr-2019 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
drivers: base: power: add proper SPDX identifiers on files that did not have them.
There were a few files in the driver core power code that did not have SPDX identifiers on them, so fix that up. A
drivers: base: power: add proper SPDX identifiers on files that did not have them.
There were a few files in the driver core power code that did not have SPDX identifiers on them, so fix that up. At the same time, remove the "free form" text that specified the license of the file, as that is impossible for any tool to properly parse.
Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27 |
|
#
0996584b |
| 05-Mar-2019 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM-runtime: Call pm_runtime_active|suspended_time() from sysfs
Avoid the open-coding of the accounted time acquisition in runtime_active|suspend_time_show() and make them call pm_runtime_active|susp
PM-runtime: Call pm_runtime_active|suspended_time() from sysfs
Avoid the open-coding of the accounted time acquisition in runtime_active|suspend_time_show() and make them call pm_runtime_active|suspended_time() instead.
Note that this change also indirectly avoids holding dev->power.lock around the do_div() computation and the sprintf() call which is an additional improvement.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
fdc56c07 |
| 05-Mar-2019 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM-runtime: Consolidate code to get active/suspended time
In a step to consolidate the code for fetching the PM-runtime active/suspended time for a device, add a common function for that and make th
PM-runtime: Consolidate code to get active/suspended time
In a step to consolidate the code for fetching the PM-runtime active/suspended time for a device, add a common function for that and make the existing pm_runtime_suspended_time() call it.
Also add a corresponding pm_runtime_active_time() calling the new common function.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Changelog, function rename ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.0, v4.19.26, v4.19.25 |
|
#
74fb4486 |
| 21-Feb-2019 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: Fix deadlock when canceling hrtimer
When rpm_resume() desactivates the autosuspend timer, it should only try to cancel hrtimer but not wait for the handler to finish, because both rpm_re
PM-runtime: Fix deadlock when canceling hrtimer
When rpm_resume() desactivates the autosuspend timer, it should only try to cancel hrtimer but not wait for the handler to finish, because both rpm_resume() and pm_suspend_timer_fn() take the power.lock.
A deadlock is possible as follows:
CPU0 CPU1 rpm_resume() spin_lock_irqsave pm_suspend_timer_fn() spin_lock_irqsave pm_runtime_deactivate_timer() hrtimer_cancel()
It is sufficient to call hrtimer_try_to_cancel() from pm_runtime_deactivate_timer(), because dev->power.timer_expires reset to 0 by it, so use that function instead of hrtimer_cancel().
Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") Reported-by: Sunzhaosheng Sun(Zhaosheng) <sunzhaosheng@hisilicon.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v4.19.24 |
|
#
36003d4c |
| 19-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
driver core: Fix PM-runtime for links added during consumer probe
Commit 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") introduced a regression that causes suppliers
driver core: Fix PM-runtime for links added during consumer probe
Commit 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") introduced a regression that causes suppliers to be suspended prematurely for device links added during consumer driver probe if the initial PM-runtime status of the consumer is "suspended" and the consumer is resumed after adding the link and before pm_runtime_put_suppliers() is called. In that case, pm_runtime_put_suppliers() will drop the rpm_active refcount for the link by one and (since rpm_active is equal to two after the preceding consumer resume) the supplier's PM-runtime usage counter will be decremented, which may cause the supplier to suspend even though the consumer's PM-runtime status is "active".
For this reason, partially revert commit 4c06c4e6cf63 as the problem it tried to fix needs to be addressed somewhat differently, and change pm_runtime_get_suppliers() and pm_runtime_put_suppliers() so that the latter only drops rpm_active references acquired by the former. [This requires adding a new field to struct device_link, but I coulnd't find a cleaner way to address the issue that would work in all cases.]
This causes pm_runtime_put_suppliers() to effectively ignore device links added during consumer probe, so device_link_add() doesn't need to worry about ensuring that suppliers will remain active after pm_runtime_put_suppliers() for links created with DL_FLAG_RPM_ACTIVE set and it only needs to bump up rpm_active by one for those links, so pm_runtime_active_link() is not necessary any more.
Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") Reported-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.19.23, v4.19.22, v4.19.21 |
|
#
4c06c4e6 |
| 12-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
driver core: Fix possible supplier PM-usage counter imbalance
If a stateless device link to a certain supplier with DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the consumer driv
driver core: Fix possible supplier PM-usage counter imbalance
If a stateless device link to a certain supplier with DL_FLAG_PM_RUNTIME set in the flags is added and then removed by the consumer driver's probe callback, the supplier's PM-runtime usage counter will be nonzero after that which effectively causes the supplier to remain "always on" going forward.
Namely, device_link_add() called to add the link invokes device_link_rpm_prepare() which notices that the consumer driver is probing, so it increments the supplier's PM-runtime usage counter with the assumption that the link will stay around until pm_runtime_put_suppliers() is called by driver_probe_device(), but if the link goes away before that point, the supplier's PM-runtime usage counter will remain nonzero.
To prevent that from happening, first rework pm_runtime_get_suppliers() and pm_runtime_put_suppliers() to use the rpm_active refounts of device links and make the latter only drop rpm_active and the supplier's PM-runtime usage counter for each link by one, unless rpm_active is one already for it. Next, modify device_link_add() to bump up the new link's rpm_active refcount and the suppliers PM-runtime usage counter by two, to prevent pm_runtime_put_suppliers(), if it is called subsequently, from suspending the supplier prematurely (in case its PM-runtime usage counter goes down to 0 in there).
Due to the way rpm_put_suppliers() works, this change does not affect runtime suspend of the consumer ends of new device links (or, generally, device links for which DL_FLAG_PM_RUNTIME has just been set).
Fixes: e2f3cd831a28 ("driver core: Fix handling of runtime PM flags in device_link_add()") Reported-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
c1567f81 |
| 12-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM-runtime: Fix __pm_runtime_set_status() race with runtime resume
Commit 4080ab083000 ("PM-runtime: Take suppliers into account in __pm_runtime_set_status()") introduced a race condition that may t
PM-runtime: Fix __pm_runtime_set_status() race with runtime resume
Commit 4080ab083000 ("PM-runtime: Take suppliers into account in __pm_runtime_set_status()") introduced a race condition that may trigger if __pm_runtime_set_status() is used incorrectly (that is, if it is called when PM-runtime is enabled for the target device and working).
In that case, if the original PM-runtime status of the device is RPM_SUSPENDED, a runtime resume of the device may occur after __pm_runtime_set_status() has dropped its power.lock spinlock and before deactivating its suppliers, so the suppliers may be deactivated while the device is PM-runtime-active which may lead to functional issues.
To avoid that, modify __pm_runtime_set_status() to check whether or not PM-runtime is enabled for the device before activating its suppliers (if the new status is RPM_ACTIVE) and either return an error if that's the case or increment the device's disable_depth counter to prevent PM-runtime from being enabled for it while the remaining part of the function is running (disable_depth is then decremented on the way out).
Fixes: 4080ab083000 ("PM-runtime: Take suppliers into account in __pm_runtime_set_status()") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
4080ab08 |
| 07-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM-runtime: Take suppliers into account in __pm_runtime_set_status()
If the target device has any suppliers, as reflected by device links to them, __pm_runtime_set_status() does not take them into a
PM-runtime: Take suppliers into account in __pm_runtime_set_status()
If the target device has any suppliers, as reflected by device links to them, __pm_runtime_set_status() does not take them into account, which is not consistent with the other parts of the PM-runtime framework and may lead to programming mistakes.
Modify __pm_runtime_set_status() to take suppliers into account by activating them upfront if the new status is RPM_ACTIVE and deactivating them on exit if the new status is RPM_SUSPENDED.
If the activation of one of the suppliers fails, the new status will be RPM_SUSPENDED and the (remaining) suppliers will be deactivated on exit (the child count of the device's parent will be dropped too then).
Of course, adding device links locking to __pm_runtime_set_status() means that it cannot be run fron interrupt context, so make it use spin_lock_irq() and spin_unlock_irq() instead of spin_lock_irqsave() and spin_unlock_irqrestore(), respectively.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.19.20 |
|
#
fed7e88c |
| 04-Feb-2019 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: update time accounting only when enabled
Update the accounting_timestamp field only when PM runtime is enabled and don't forget to account the last state before disabling it.
Suggested-
PM-runtime: update time accounting only when enabled
Update the accounting_timestamp field only when PM runtime is enabled and don't forget to account the last state before disabling it.
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Minor cleanups ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
c155f649 |
| 04-Feb-2019 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: Switch accounting over to ktime_get_mono_fast_ns()
Similar to what happened whith autosuspend, a deadlock has been reported with PM-runtime accounting in the call path:
change_clocksour
PM-runtime: Switch accounting over to ktime_get_mono_fast_ns()
Similar to what happened whith autosuspend, a deadlock has been reported with PM-runtime accounting in the call path:
change_clocksource ... write_seqcount_begin ... timekeeping_update ... sh_cmt_clocksource_enable ... rpm_resume update_pm_runtime_accounting ktime_get do read_seqcount_begin while read_seqcount_retry .... write_seqcount_end
Make PM-runtime accounting use ktime_get_mono_fast_ns() to avoid this problem.
With ktime_get_mono_fast_ns(), the timestamp is not guaranteed to be monotonic across an update of timekeeping and as a result time can go backward. Add a test to skip accounting for such situation which should stay exceptional.
Fixes: a08c2a5a3194 ("PM-runtime: Replace jiffies-based accounting with ktime-based accounting") Reported-by: Biju Das <biju.das@bp.renesas.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Subject, changelog, comment cleanup ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v4.19.19 |
|
#
f800ea32 |
| 30-Jan-2019 |
Ladislav Michl <ladis@linux-mips.org> |
PM-runtime: Optimize pm_runtime_autosuspend_expiration()
pm_runtime_autosuspend_expiration calls ktime_get_mono_fast_ns() even when its returned value may be unused. Therefore get the current time l
PM-runtime: Optimize pm_runtime_autosuspend_expiration()
pm_runtime_autosuspend_expiration calls ktime_get_mono_fast_ns() even when its returned value may be unused. Therefore get the current time later and remove gotos while there.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
a1fdbfbb |
| 31-Jan-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
driver core: Do not call rpm_put_suppliers() in pm_runtime_drop_link()
Calling rpm_put_suppliers() from pm_runtime_drop_link() is excessive as it affects all suppliers of the consumer device and not
driver core: Do not call rpm_put_suppliers() in pm_runtime_drop_link()
Calling rpm_put_suppliers() from pm_runtime_drop_link() is excessive as it affects all suppliers of the consumer device and not just the one pointed to by the device link being dropped. Worst case it may cause the consumer device to stop working unexpectedly. Moreover, in principle it is racy with respect to runtime PM of the consumer device.
To avoid these problems drop runtime PM references on the particular supplier pointed to by the link in question only and do that after the link has been dropped from the consumer device's list of links to suppliers, which is in device_link_free().
Fixes: a0504aecba76 ("PM / runtime: Drop usage count for suppliers at device link removal") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e2f3cd83 |
| 31-Jan-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
driver core: Fix handling of runtime PM flags in device_link_add()
After commit ead18c23c263 ("driver core: Introduce device links reference counting"), if there is a link between the given supplier
driver core: Fix handling of runtime PM flags in device_link_add()
After commit ead18c23c263 ("driver core: Introduce device links reference counting"), if there is a link between the given supplier and the given consumer already, device_link_add() will refcount it and return it unconditionally without updating its flags. It is possible, however, that the second (or any subsequent) caller of device_link_add() for the same consumer-supplier pair will pass DL_FLAG_PM_RUNTIME, possibly along with DL_FLAG_RPM_ACTIVE, in flags to it and the existing link may not behave as expected then.
First, if DL_FLAG_PM_RUNTIME is not set in the existing link's flags at all, it needs to be set like during the original initialization of the link.
Second, if DL_FLAG_RPM_ACTIVE is passed to device_link_add() in flags (in addition to DL_FLAG_PM_RUNTIME), the existing link should to be updated to reflect the "active" runtime PM configuration of the consumer-supplier pair and extra care must be taken here to avoid possible destructive races with runtime PM of the consumer.
To that end, redefine the rpm_active field in struct device_link as a refcount, initialize it to 1 and make rpm_resume() (for the consumer) and device_link_add() increment it whenever they acquire a runtime PM reference on the supplier device. Accordingly, make rpm_suspend() (for the consumer) and pm_runtime_clean_up_links() decrement it and drop runtime PM references to the supplier device in a loop until rpm_active becones 1 again.
Fixes: ead18c23c263 ("driver core: Introduce device links reference counting") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.19.18 |
|
#
a08c2a5a |
| 23-Jan-2019 |
Thara Gopinath <thara.gopinath@linaro.org> |
PM-runtime: Replace jiffies-based accounting with ktime-based accounting
Replace jiffies-based accounting for runtime_active_time and runtime_suspended_time with ktime-based accounting. This makes t
PM-runtime: Replace jiffies-based accounting with ktime-based accounting
Replace jiffies-based accounting for runtime_active_time and runtime_suspended_time with ktime-based accounting. This makes the runtime debug counters inline with genpd and other PM subsytems which use ktime-based accounting.
Timekeeping is initialized before driver_init(). It's only at that time that PM-runtime can be enabled.
Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> [switch from ktime to raw nsec] Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
58456488 |
| 23-Jan-2019 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: update accounting_timestamp on enable
Initializing accounting_timestamp to something different from 0 during pm_runtime_init() doesn't make sense and puts an artificial ordering constrai
PM-runtime: update accounting_timestamp on enable
Initializing accounting_timestamp to something different from 0 during pm_runtime_init() doesn't make sense and puts an artificial ordering constraint between timekeeping_init() and pm_runtime_init().
PM-runtime should start time accounting only when it is enabled and discard the period when disabled.
Set accounting_timestamp to now when enabling PM-runtime.
Suggested-by: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|