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_run
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
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 ...
|
#
e431f2d7 |
| 06-Mar-2019 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'driver-core-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big driver core patchset for 5.1-
Merge tag 'driver-core-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big driver core patchset for 5.1-rc1 More patches than "normal" here this merge window, due to some work in the driver core by Alexander Duyck to rework the async probe functionality to work better for a number of devices, and independant work from Rafael for the device link functionality to make it work "correctly". Also in here is: - lots of BUS_ATTR() removals, the macro is about to go away - firmware test fixups - ihex fixups and simplification - component additions (also includes i915 patches) - lots of minor coding style fixups and cleanups. All of these have been in linux-next for a while with no reported issues" * tag 'driver-core-5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (65 commits) driver core: platform: remove misleading err_alloc label platform: set of_node in platform_device_register_full() firmware: hardcode the debug message for -ENOENT driver core: Add missing description of new struct device_link field driver core: Fix PM-runtime for links added during consumer probe drivers/component: kerneldoc polish async: Add cmdline option to specify drivers to be async probed driver core: Fix possible supplier PM-usage counter imbalance PM-runtime: Fix __pm_runtime_set_status() race with runtime resume driver: platform: Support parsing GpioInt 0 in platform_get_irq() selftests: firmware: fix verify_reqs() return value Revert "selftests: firmware: remove use of non-standard diff -Z option" Revert "selftests: firmware: add CONFIG_FW_LOADER_USER_HELPER_FALLBACK to config" device: Fix comment for driver_data in struct device kernfs: Allocating memory for kernfs_iattrs with kmem_cache. sysfs: remove unused include of kernfs-internal.h driver core: Postpone DMA tear-down until after devres release driver core: Document limitation related to DL_FLAG_RPM_ACTIVE PM-runtime: Take suppliers into account in __pm_runtime_set_status() device.h: Add __cold to dev_<level> logging functions ...
show more ...
|
#
656f72bb |
| 24-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Merge back earlier PM core material for v5.1.
|
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
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 cause
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
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 conditio
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 ...
|
#
9481caf3 |
| 11-Feb-2019 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Merge 5.0-rc6 into driver-core-next We need the debugfs fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
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
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.
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:
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
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 ...
|
#
1cc9c595 |
| 01-Feb-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Merge back earlier PM core material for v5.1.
|
#
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 de
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 gi
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.
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 order
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 ...
|
#
15efb47d |
| 30-Jan-2019 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: Fix deadlock with ktime_get() A deadlock has been seen when swicthing clocksources which use PM-runtime. The call path is: change_clocksource ... wr
PM-runtime: Fix deadlock with ktime_get() A deadlock has been seen when swicthing clocksources which use PM-runtime. The call path is: change_clocksource ... write_seqcount_begin ... timekeeping_update ... sh_cmt_clocksource_enable ... rpm_resume pm_runtime_mark_last_busy ktime_get do read_seqcount_begin while read_seqcount_retry .... write_seqcount_end Although we should be safe because we haven't yet changed the clocksource at that time, we can't do that because of seqcount protection. Use ktime_get_mono_fast_ns() instead which is lock safe for such cases. With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be monotonic across an update and as a result can goes backward. According to update_fast_timekeeper() description: "In the worst case, this can result is a slightly wrong timestamp (a few nanoseconds)". For PM-runtime autosuspend, this means only that the suspend decision may be slightly suboptimal. Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers") 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> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12 |
|
#
8a62ffe2 |
| 21-Dec-2018 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: Add new interface to get accounted time Some drivers (like i915/drm) needs to get the accounted suspended time. pm_runtime_suspended_time() will return the suspended accounte
PM-runtime: Add new interface to get accounted time Some drivers (like i915/drm) needs to get the accounted suspended time. pm_runtime_suspended_time() will return the suspended accounted time in ns unit. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
ca27e4cd |
| 10-Jan-2019 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: Fix autosuspend_delay on 32bits arch Cast autosuspend_delay to u64 to make sure that the full computation of 'expires' or slack will be done in u64, even on 32bits arch.
PM-runtime: Fix autosuspend_delay on 32bits arch Cast autosuspend_delay to u64 to make sure that the full computation of 'expires' or slack will be done in u64, even on 32bits arch. Otherwise, any delay greater than 2^31 nsec can overflow if signed 32bits is used when converting delay from msec to nsec. Fixes: 8234f6734c5d (PM-runtime: Switch autosuspend over to using hrtimers) Reported-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
1f7b7081 |
| 09-Jan-2019 |
Ladislav Michl <ladis@linux-mips.org> |
PM-runtime: Fix 'jiffies' in comments after switch to hrtimers PM-runtime now uses the hrtimers infrastructure for autosuspend, however comments still reference 'jiffies'. Fixes
PM-runtime: Fix 'jiffies' in comments after switch to hrtimers PM-runtime now uses the hrtimers infrastructure for autosuspend, however comments still reference 'jiffies'. Fixes: 8234f6734c5d (PM-runtime: Switch autosuspend over to using hrtimers) Signed-off-by: Ladislav Michl <ladis@linux-mips.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v4.19.11, v4.19.10 |
|
#
8234f673 |
| 14-Dec-2018 |
Vincent Guittot <vincent.guittot@linaro.org> |
PM-runtime: Switch autosuspend over to using hrtimers PM-runtime uses the timer infrastructure for autosuspend. This implies that the minimum time before autosuspending a device is in th
PM-runtime: Switch autosuspend over to using hrtimers PM-runtime uses the timer infrastructure for autosuspend. This implies that the minimum time before autosuspending a device is in the range of 1 tick included to 2 ticks excluded -On arm64 this means between 4ms and 8ms with default jiffies configuration -And on arm, it is between 10ms and 20ms These values are quite high for embedded systems which sometimes want the duration to be in the range of 1 ms. It is possible to switch autosuspend over to using hrtimers to get finer granularity for short durations and take advantage of slack to retain some margins and get long timeouts with minimum wakeups. On an arm64 platform that uses 1ms for autosuspending timeout of its GPU, idle power is reduced by 10% with hrtimer. The latency impact on arm64 hikey octo cores is: - mark_last_busy: from 1.11 us to 1.25 us - rpm_suspend: from 15.54 us to 15.38 us [Only the code path of rpm_suspend() that starts hrtimer has been measured.] arm64 image (arm64 default defconfig) decreases by around 3KB with following details: $ size vmlinux-timer text data bss dec hex filename 12034646 6869268 386840 19290754 1265a82 vmlinux $ size vmlinux-hrtimer text data bss dec hex filename 12030550 6870164 387032 19287746 1264ec2 vmlinux The latency impact on arm 32bits snowball dual cores is : - mark_last_busy: from 0.31 us usec to 0.77 us - rpm_suspend: from 6.83 us to 6.67 usec The increase of the image for snowball platform that I used for testing performance impact, is neglictable (244B). $ size vmlinux-timer text data bss dec hex filename 7157961 2119580 264120 9541661 91981d build-ux500/vmlinux size vmlinux-hrtimer text data bss dec hex filename 7157773 2119884 264248 9541905 919911 vmlinux-hrtimer And arm 32bits image (multi_v7_defconfig) increases by around 1.7KB with following details: $ size vmlinux-timer text data bss dec hex filename 13304443 6803420 402768 20510631 138f7a7 vmlinux $ size vmlinux-hrtimer text data bss dec hex filename 13304299 6805276 402768 20512343 138fe57 vmlinux 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 ...
|
Revision tags: v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2 |
|
#
b06c0b2f |
| 12-Jun-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "PM / runtime: Fixup reference counting of device link suppliers at probe" Revert commit 1e8378619841 (PM / runtime: Fixup reference counting of device link suppliers at probe), a
Revert "PM / runtime: Fixup reference counting of device link suppliers at probe" Revert commit 1e8378619841 (PM / runtime: Fixup reference counting of device link suppliers at probe), as it has introduced a regression and the condition it was designed to address should be covered by the existing code. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v4.17.1, v4.17 |
|
#
a0504aec |
| 24-May-2018 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM / runtime: Drop usage count for suppliers at device link removal In the case consumer device is runtime resumed, while the link to the supplier is removed, the earlier call to pm_runt
PM / runtime: Drop usage count for suppliers at device link removal In the case consumer device is runtime resumed, while the link to the supplier is removed, the earlier call to pm_runtime_get_sync() made from rpm_get_suppliers() does not get properly balanced with a corresponding call to pm_runtime_put(). This leads to that suppliers remains to be runtime resumed forever, while they don't need to. Let's fix the behaviour by calling rpm_put_suppliers() when dropping a device link. Not that, since rpm_put_suppliers() checks the link->rpm_active flag, we can correctly avoid to call pm_runtime_put() in cases when we shouldn't. Reported-by: Todor Tomov <todor.tomov@linaro.org> Fixes: 21d5c57b3726 (PM / runtime: Use device links) Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|