commit 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 upstream.
It is generally unsafe to call put_device() with dpm_list_mtx held,
because the given device's release routine may carry out an action
depending on that lock which then may deadlock, so modify the
system-wide suspend and resume of devices to always drop dpm_list_mtx
before calling put_device() (and adjust white space somewhat while
at it).
For instance, this prevents the following splat from showing up in
the kernel log after a system resume in certain configurations:
[ 3290.969514] ======================================================
[ 3290.969517] WARNING: possible circular locking dependency detected
[ 3290.969519] 5.15.0+ #2420 Tainted: G S
[ 3290.969523] ------------------------------------------------------
[ 3290.969525] systemd-sleep/4553 is trying to acquire lock:
[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0
[ 3290.969554]
but task is already holding lock:
[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.969571]
which lock already depends on the new lock.
[ 3290.969573]
the existing dependency chain (in reverse order) is:
[ 3290.969575]
-> #3 (dpm_list_mtx){+.+.}-{3:3}:
[ 3290.969583] __mutex_lock+0x9d/0xa30
[ 3290.969591] device_pm_add+0x2e/0xe0
[ 3290.969597] device_add+0x4d5/0x8f0
[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth]
[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth]
[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth]
[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969842] process_one_work+0x2aa/0x650
[ 3290.969851] worker_thread+0x39/0x400
[ 3290.969859] kthread+0x142/0x170
[ 3290.969865] ret_from_fork+0x22/0x30
[ 3290.969872]
-> #2 (&hdev->lock){+.+.}-{3:3}:
[ 3290.969881] __mutex_lock+0x9d/0xa30
[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth]
[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth]
[ 3290.969978] process_one_work+0x2aa/0x650
[ 3290.969985] worker_thread+0x39/0x400
[ 3290.969993] kthread+0x142/0x170
[ 3290.969999] ret_from_fork+0x22/0x30
[ 3290.970004]
-> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}:
[ 3290.970013] process_one_work+0x27d/0x650
[ 3290.970020] worker_thread+0x39/0x400
[ 3290.970028] kthread+0x142/0x170
[ 3290.970033] ret_from_fork+0x22/0x30
[ 3290.970038]
-> #0 ((wq_completion)hci0#2){+.+.}-{0:0}:
[ 3290.970047] __lock_acquire+0x15cb/0x1b50
[ 3290.970054] lock_acquire+0x26c/0x300
[ 3290.970059] flush_workqueue+0xae/0x4a0
[ 3290.970066] drain_workqueue+0xa1/0x130
[ 3290.970073] destroy_workqueue+0x34/0x1f0
[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970195] device_release+0x33/0x90
[ 3290.970201] kobject_release+0x63/0x160
[ 3290.970211] dpm_resume+0x164/0x3e0
[ 3290.970215] dpm_resume_end+0xd/0x20
[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970229] pm_suspend+0x26b/0x310
[ 3290.970236] state_store+0x42/0x90
[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970251] new_sync_write+0x125/0x1c0
[ 3290.970257] vfs_write+0x360/0x3c0
[ 3290.970263] ksys_write+0xa7/0xe0
[ 3290.970269] do_syscall_64+0x3a/0x80
[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970284]
other info that might help us debug this:
[ 3290.970285] Chain exists of:
(wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx
[ 3290.970297] Possible unsafe locking scenario:
[ 3290.970299] CPU0 CPU1
[ 3290.970300] ---- ----
[ 3290.970302] lock(dpm_list_mtx);
[ 3290.970306] lock(&hdev->lock);
[ 3290.970310] lock(dpm_list_mtx);
[ 3290.970314] lock((wq_completion)hci0#2);
[ 3290.970319]
*** DEADLOCK ***
[ 3290.970321] 7 locks held by systemd-sleep/4553:
[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0
[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0
[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0
[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90
[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310
[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80
[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0
[ 3290.970428]
stack backtrace:
[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420
[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019
[ 3290.970441] Call Trace:
[ 3290.970446] dump_stack_lvl+0x44/0x57
[ 3290.970454] check_noncircular+0x105/0x120
[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50
[ 3290.970474] __lock_acquire+0x15cb/0x1b50
[ 3290.970487] lock_acquire+0x26c/0x300
[ 3290.970493] ? flush_workqueue+0x87/0x4a0
[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60
[ 3290.970510] ? lockdep_init_map_type+0x58/0x240
[ 3290.970519] flush_workqueue+0xae/0x4a0
[ 3290.970526] ? flush_workqueue+0x87/0x4a0
[ 3290.970544] ? drain_workqueue+0xa1/0x130
[ 3290.970552] drain_workqueue+0xa1/0x130
[ 3290.970561] destroy_workqueue+0x34/0x1f0
[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth]
[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth]
[ 3290.970687] device_release+0x33/0x90
[ 3290.970695] kobject_release+0x63/0x160
[ 3290.970705] dpm_resume+0x164/0x3e0
[ 3290.970710] ? dpm_resume_early+0x251/0x3b0
[ 3290.970718] dpm_resume_end+0xd/0x20
[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0
[ 3290.970737] pm_suspend+0x26b/0x310
[ 3290.970746] state_store+0x42/0x90
[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0
[ 3290.970764] new_sync_write+0x125/0x1c0
[ 3290.970777] vfs_write+0x360/0x3c0
[ 3290.970785] ksys_write+0xa7/0xe0
[ 3290.970794] do_syscall_64+0x3a/0x80
[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 3290.970811] RIP: 0033:0x7f41b1328164
[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83
[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164
[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004
[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0
[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004
[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 928265e3601cde78c7e0a3e518a93b27defed3b1 upstream.
There is no reason to allow "syscore" devices to runtime-suspend
during system-wide PM transitions, because they are subject to the
same possible failure modes as any other devices in that respect.
Accordingly, change device_prepare() and device_complete() to call
pm_runtime_get_noresume() and pm_runtime_put(), respectively, for
"syscore" devices too.
Fixes: 057d51a1268f ("Merge branch 'pm-sleep'")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a9344cd0aa4499beb3772bbecb40bb78888c0e1 upstream.
There are variables(power.may_skip_resume and dev->power.must_resume)
and DPM_FLAG_MAY_SKIP_RESUME flags to control the resume of devices after
a system wide suspend transition.
Setting the DPM_FLAG_MAY_SKIP_RESUME flag means that the driver allows
its "noirq" and "early" resume callbacks to be skipped if the device
can be left in suspend after a system-wide transition into the working
state. PM core determines that the driver's "noirq" and "early" resume
callbacks should be skipped or not with dev_pm_skip_resume() function by
checking power.may_skip_resume variable.
power.must_resume variable is getting set to false in __device_suspend()
function without checking device's DPM_FLAG_MAY_SKIP_RESUME settings.
In problematic scenario, where all the devices in the suspend_late
stage are successful and some device can fail to suspend in
suspend_noirq phase. So some devices successfully suspended in suspend_late
stage are not getting chance to execute __device_suspend_noirq()
to set dev->power.must_resume variable to true and not getting
resumed in early_resume phase.
Add a check for device's DPM_FLAG_MAY_SKIP_RESUME flag before
setting power.must_resume variable in __device_suspend function.
Fixes: 6e176bf8d461 ("PM: sleep: core: Do not skip callbacks in the resume phase")
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0560204b360a332c321124dbc5cdfd3364533a74 upstream. If there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume. Cc: <stable@vger.kernel.org> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Rafael J. Wysocki <rafael@kernel.org> Link: https://lore.kernel.org/r/20210903084937.19392-2-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
GENPD core doesn't support handling performance state changes while
consumer device is runtime-suspended or when runtime PM is disabled.
GENPD core may override performance state that was configured by device
driver while RPM of the device was disabled or device was RPM-suspended.
Let's close that gap by allowing drivers to control performance state
while RPM of a consumer device is disabled and to set up performance
state of RPM-suspended device that will be applied by GENPD core on
RPM-resume of the device.
Fixes: 5937c3ce2122 ("PM: domains: Drop/restore performance state votes for devices at runtime PM")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* pm-cpuidle: cpuidle: qcom: Add SPM register data for MSM8226 dt-bindings: arm: msm: Add SAW2 for MSM8226 * pm-sleep: PM: sleep: Use ktime_us_delta() in initcall_debug_report() * pm-domains: PM: domains: Shrink locking area of the gpd_list_lock
On trogdor devices I see the following lockdep splat when stopping
youtube with lockdep enabled in the kernel.
======================================================
WARNING: possible circular locking dependency detected
5.13.0-rc2 #71 Not tainted
------------------------------------------------------
ThreadPoolSingl/3969 is trying to acquire lock:
ffffff80d4d5c080 (&inst->lock#3){+.+.}-{3:3}, at: vdec_buf_cleanup+0x3c/0x17c [venus_dec]
but task is already holding lock:
ffffff80d3c3c4f8 (&q->mmap_lock){+.+.}-{3:3}, at: vb2_core_reqbufs+0xe4/0x390 [videobuf2_common]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #5 (&q->mmap_lock){+.+.}-{3:3}:
__mutex_lock_common+0xcc/0xb88
mutex_lock_nested+0x5c/0x68
vb2_mmap+0xf4/0x290 [videobuf2_common]
v4l2_m2m_fop_mmap+0x44/0x50 [v4l2_mem2mem]
v4l2_mmap+0x5c/0xa4
mmap_region+0x310/0x5a4
do_mmap+0x348/0x43c
vm_mmap_pgoff+0xfc/0x178
ksys_mmap_pgoff+0x84/0xfc
__arm64_compat_sys_aarch32_mmap2+0x2c/0x38
invoke_syscall+0x54/0x110
el0_svc_common+0x88/0xf0
do_el0_svc_compat+0x28/0x34
el0_svc_compat+0x24/0x34
el0_sync_compat_handler+0xc0/0xf0
el0_sync_compat+0x19c/0x1c0
-> #4 (&mm->mmap_lock){++++}-{3:3}:
__might_fault+0x60/0x88
filldir64+0x124/0x3a0
dcache_readdir+0x7c/0x1ec
iterate_dir+0xc4/0x184
__arm64_sys_getdents64+0x78/0x170
invoke_syscall+0x54/0x110
el0_svc_common+0xa8/0xf0
do_el0_svc_compat+0x28/0x34
el0_svc_compat+0x24/0x34
el0_sync_compat_handler+0xc0/0xf0
el0_sync_compat+0x19c/0x1c0
-> #3 (&sb->s_type->i_mutex_key#3){++++}-{3:3}:
down_write+0x94/0x1f4
start_creating+0xb0/0x174
debugfs_create_dir+0x28/0x138
opp_debug_register+0x88/0xc0
_add_opp_dev+0x84/0x9c
_add_opp_table_indexed+0x16c/0x310
_of_add_table_indexed+0x70/0xb5c
dev_pm_opp_of_add_table_indexed+0x20/0x2c
of_genpd_add_provider_onecell+0xc4/0x1c8
rpmhpd_probe+0x21c/0x278
platform_probe+0xb4/0xd4
really_probe+0x140/0x35c
driver_probe_device+0x90/0xcc
__device_attach_driver+0xa4/0xc0
bus_for_each_drv+0x8c/0xd8
__device_attach+0xc4/0x150
device_initial_probe+0x20/0x2c
bus_probe_device+0x40/0xa4
device_add+0x22c/0x3fc
of_device_add+0x44/0x54
of_platform_device_create_pdata+0xb0/0xf4
of_platform_bus_create+0x1d0/0x350
of_platform_populate+0x80/0xd4
devm_of_platform_populate+0x64/0xb0
rpmh_rsc_probe+0x378/0x3dc
platform_probe+0xb4/0xd4
really_probe+0x140/0x35c
driver_probe_device+0x90/0xcc
__device_attach_driver+0xa4/0xc0
bus_for_each_drv+0x8c/0xd8
__device_attach+0xc4/0x150
device_initial_probe+0x20/0x2c
bus_probe_device+0x40/0xa4
device_add+0x22c/0x3fc
of_device_add+0x44/0x54
of_platform_device_create_pdata+0xb0/0xf4
of_platform_bus_create+0x1d0/0x350
of_platform_bus_create+0x21c/0x350
of_platform_populate+0x80/0xd4
of_platform_default_populate_init+0xb8/0xd4
do_one_initcall+0x1b4/0x400
do_initcall_level+0xa8/0xc8
do_initcalls+0x5c/0x9c
do_basic_setup+0x2c/0x38
kernel_init_freeable+0x1a4/0x1ec
kernel_init+0x20/0x118
ret_from_fork+0x10/0x30
-> #2 (gpd_list_lock){+.+.}-{3:3}:
__mutex_lock_common+0xcc/0xb88
mutex_lock_nested+0x5c/0x68
__genpd_dev_pm_attach+0x70/0x18c
genpd_dev_pm_attach_by_id+0xe4/0x158
genpd_dev_pm_attach_by_name+0x48/0x60
dev_pm_domain_attach_by_name+0x2c/0x38
dev_pm_opp_attach_genpd+0xac/0x160
vcodec_domains_get+0x94/0x14c [venus_core]
core_get_v4+0x150/0x188 [venus_core]
venus_probe+0x138/0x444 [venus_core]
platform_probe+0xb4/0xd4
really_probe+0x140/0x35c
driver_probe_device+0x90/0xcc
device_driver_attach+0x58/0x7c
__driver_attach+0xc8/0xe0
bus_for_each_dev+0x88/0xd4
driver_attach+0x30/0x3c
bus_add_driver+0x10c/0x1e0
driver_register+0x70/0x108
__platform_driver_register+0x30/0x3c
0xffffffde113e1044
do_one_initcall+0x1b4/0x400
do_init_module+0x64/0x1fc
load_module+0x17f4/0x1958
__arm64_sys_finit_module+0xb4/0xf0
invoke_syscall+0x54/0x110
el0_svc_common+0x88/0xf0
do_el0_svc_compat+0x28/0x34
el0_svc_compat+0x24/0x34
el0_sync_compat_handler+0xc0/0xf0
el0_sync_compat+0x19c/0x1c0
-> #1 (&opp_table->genpd_virt_dev_lock){+.+.}-{3:3}:
__mutex_lock_common+0xcc/0xb88
mutex_lock_nested+0x5c/0x68
_set_required_opps+0x74/0x120
_set_opp+0x94/0x37c
dev_pm_opp_set_rate+0xa0/0x194
core_clks_set_rate+0x28/0x58 [venus_core]
load_scale_v4+0x228/0x2b4 [venus_core]
session_process_buf+0x160/0x198 [venus_core]
venus_helper_vb2_buf_queue+0xcc/0x130 [venus_core]
vdec_vb2_buf_queue+0xc4/0x140 [venus_dec]
__enqueue_in_driver+0x164/0x188 [videobuf2_common]
vb2_core_qbuf+0x13c/0x47c [videobuf2_common]
vb2_qbuf+0x88/0xec [videobuf2_v4l2]
v4l2_m2m_qbuf+0x84/0x15c [v4l2_mem2mem]
v4l2_m2m_ioctl_qbuf+0x24/0x30 [v4l2_mem2mem]
v4l_qbuf+0x54/0x68
__video_do_ioctl+0x2bc/0x3bc
video_usercopy+0x558/0xb04
video_ioctl2+0x24/0x30
v4l2_ioctl+0x58/0x68
v4l2_compat_ioctl32+0x84/0xa0
__arm64_compat_sys_ioctl+0x12c/0x140
invoke_syscall+0x54/0x110
el0_svc_common+0x88/0xf0
do_el0_svc_compat+0x28/0x34
el0_svc_compat+0x24/0x34
el0_sync_compat_handler+0xc0/0xf0
el0_sync_compat+0x19c/0x1c0
-> #0 (&inst->lock#3){+.+.}-{3:3}:
__lock_acquire+0x248c/0x2d6c
lock_acquire+0x240/0x314
__mutex_lock_common+0xcc/0xb88
mutex_lock_nested+0x5c/0x68
vdec_buf_cleanup+0x3c/0x17c [venus_dec]
__vb2_queue_free+0x98/0x204 [videobuf2_common]
vb2_core_reqbufs+0x14c/0x390 [videobuf2_common]
vb2_reqbufs+0x58/0x74 [videobuf2_v4l2]
v4l2_m2m_reqbufs+0x58/0x90 [v4l2_mem2mem]
v4l2_m2m_ioctl_reqbufs+0x24/0x30 [v4l2_mem2mem]
v4l_reqbufs+0x58/0x6c
__video_do_ioctl+0x2bc/0x3bc
video_usercopy+0x558/0xb04
video_ioctl2+0x24/0x30
v4l2_ioctl+0x58/0x68
v4l2_compat_ioctl32+0x84/0xa0
__arm64_compat_sys_ioctl+0x12c/0x140
invoke_syscall+0x54/0x110
el0_svc_common+0x88/0xf0
do_el0_svc_compat+0x28/0x34
el0_svc_compat+0x24/0x34
el0_sync_compat_handler+0xc0/0xf0
el0_sync_compat+0x19c/0x1c0
other info that might help us debug this:
Chain exists of:
&inst->lock#3 --> &mm->mmap_lock --> &q->mmap_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&q->mmap_lock);
lock(&mm->mmap_lock);
lock(&q->mmap_lock);
lock(&inst->lock#3);
*** DEADLOCK ***
1 lock held by ThreadPoolSingl/3969:
#0: ffffff80d3c3c4f8 (&q->mmap_lock){+.+.}-{3:3}, at: vb2_core_reqbufs+0xe4/0x390 [videobuf2_common]
stack backtrace:
CPU: 2 PID: 3969 Comm: ThreadPoolSingl Not tainted 5.13.0-rc2 #71
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
Call trace:
dump_backtrace+0x0/0x1b4
show_stack+0x24/0x30
dump_stack+0xe0/0x15c
print_circular_bug+0x32c/0x388
check_noncircular+0x138/0x140
__lock_acquire+0x248c/0x2d6c
lock_acquire+0x240/0x314
__mutex_lock_common+0xcc/0xb88
mutex_lock_nested+0x5c/0x68
vdec_buf_cleanup+0x3c/0x17c [venus_dec]
__vb2_queue_free+0x98/0x204 [videobuf2_common]
vb2_core_reqbufs+0x14c/0x390 [videobuf2_common]
vb2_reqbufs+0x58/0x74 [videobuf2_v4l2]
v4l2_m2m_reqbufs+0x58/0x90 [v4l2_mem2mem]
v4l2_m2m_ioctl_reqbufs+0x24/0x30 [v4l2_mem2mem]
v4l_reqbufs+0x58/0x6c
__video_do_ioctl+0x2bc/0x3bc
video_usercopy+0x558/0xb04
video_ioctl2+0x24/0x30
v4l2_ioctl+0x58/0x68
v4l2_compat_ioctl32+0x84/0xa0
__arm64_compat_sys_ioctl+0x12c/0x140
invoke_syscall+0x54/0x110
el0_svc_common+0x88/0xf0
do_el0_svc_compat+0x28/0x34
el0_svc_compat+0x24/0x34
el0_sync_compat_handler+0xc0/0xf0
el0_sync_compat+0x19c/0x1c0
The 'gpd_list_lock' is nominally named as such to protect the 'gpd_list'
from concurrent access and mutation. Unfortunately, holding that mutex
around various OPP framework calls leads to lockdep splats because now
we're doing various operations in OPP core such as registering with
debugfs while holding the list lock. We don't need to hold any list
mutex while we're calling into OPP, so let's shrink the locking area of
the 'gpd_list_lock' so that lockdep isn't triggered. This also helps
reduce contention on this lock, which probably doesn't matter much but
at least is nice to have.
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-pm@vger.kernel.org>
Cc: Viresh Kumar <vireshk@kernel.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Use ktime_us_delta() to make the debug log more precise instead of shifting the return value of ktime_to_ns() applied to a ktime_sub() result by 10 bit positions to the right. Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com> [ rjw: Changelog rewrite, subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* pm-domains: PM: domains: Drop/restore performance state votes for devices at runtime PM PM: domains: Return early if perf state is already set for the device PM: domains: Split code in dev_pm_genpd_set_performance_state() PM: domains: fix some kernel-doc issues * pm-devfreq: PM / devfreq: passive: Fix get_target_freq when not using required-opp dt-bindings: devfreq: tegra30-actmon: Add cooling-cells dt-bindings: devfreq: tegra30-actmon: Convert to schema PM / devfreq: userspace: Use DEVICE_ATTR_RW macro PM / devfreq: imx8m-ddrc: Remove DEVFREQ_GOV_SIMPLE_ONDEMAND dependency PM / devfreq: tegra30: Support thermal cooling PM / devfreq: imx-bus: Remove imx_bus_get_dev_status PM / devfreq: Add missing error code in devfreq_add_device()
* pm-core: PM: runtime: Clarify documentation when callbacks are unassigned PM: runtime: Allow unassigned ->runtime_suspend|resume callbacks PM: runtime: Improve path in rpm_idle() when no callback PM: runtime: document common mistake with pm_runtime_get_sync() * pm-sleep: PM: hibernate: remove leading spaces before tabs PM: sleep: remove trailing spaces and tabs PM: hibernate: fix spelling mistakes PM: wakeirq: Set IRQF_NO_AUTOEN when requesting the IRQ