Testing out 3.19-rc6 on my 2014 Thinkpad X1 Carbon (Haswell) resulted in
this WARN at boot (and pretty frequently afterwards):
WARNING: CPU: 0 PID: 989 at drivers/gpu/drm/i915/intel_pm.c:4377 gen6_set_rps+0x371/0x3c0()
WARN_ON(val > dev_priv->rps.max_freq_softlimit)
Modules linked in:
CPU: 0 PID: 989 Comm: kworker/0:2 Not tainted 3.19.0-rc6 #31
Hardware name: LENOVO 20A7002WUS/20A7002WUS, BIOS GRET38WW (1.15 ) 05/29/2014
Workqueue: events intel_gen6_powersave_work
0000000000000000 ffffffff81a82dd0 ffffffff817f099e ffff88021451bd28
ffffffff8107d107 ffff8802148e0000 0000000000000022 ffff8802148e86f0
ffff88021498f000 0000000000040000 ffffffff8107d185 ffffffff81a83448
Call Trace:
[<ffffffff817f099e>] ? dump_stack+0x40/0x50
[<ffffffff8107d107>] ? warn_slowpath_common+0x77/0xb0
[<ffffffff8107d185>] ? warn_slowpath_fmt+0x45/0x50
[<ffffffff813c6ff1>] ? gen6_set_rps+0x371/0x3c0
[<ffffffff813caa10>] ? intel_gen6_powersave_work+0x780/0x1180
[<ffffffff81090c50>] ? process_one_work+0x130/0x350
[<ffffffff81091274>] ? worker_thread+0x114/0x450
[<ffffffff81091160>] ? rescuer_thread+0x2f0/0x2f0
[<ffffffff810954ec>] ? kthread+0xbc/0xe0
[<ffffffff81095430>] ? kthread_create_on_node+0x170/0x170
[<ffffffff817f86ac>] ? ret_from_fork+0x7c/0xb0
[<ffffffff81095430>] ? kthread_create_on_node+0x170/0x170
---[ end trace c3ac159c87b9b234 ]---
I bisected this back to:
commit 93ee29203f506582cca2bcec5f05041526d9ab0a
Author: Tom O'Rourke <Tom.O'Rourke@xxxxxxxxx>
Date: Wed Nov 19 14:21:52 2014 -0800
drm/i915: Use efficient frequency for HSW/BDW
Added gen6_init_rps_frequencies() to initialize
the rps frequency values. This function replaces
parse_rp_state_cap(). In addition to reading RPn,
RP0, and RP1 from RP_STATE_CAP register, the new
function reads efficient frequency (aka RPe) from
pcode for Haswell and Broadwell and sets the turbo
softlimits. The turbo minimum frequency softlimit
is set to RPe for Haswell and Broadwell and to RPn
otherwise.
For RPe, the efficiency is based on the frequency/power
ratio (MHz/W); this is considering GT power and not
package power. The efficent frequency is the highest
frequency for which the frequency/power ratio is within
some threshold of the highest frequency/power ratio.
A fixed decrease in frequency results in smaller
decrease in power at frequencies less than RPe than
at frequencies above RPe.
v2: Following suggestions from Chris Wilson and
Daniel Vetter to extend and rename parse_rp_state_cap
and to open-code a poorly named function.
Signed-off-by: Tom O'Rourke <Tom.O'Rourke@xxxxxxxxx>
Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
[danvet: Remove unused variables.]
Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
I'm not at all familiar with this hardware, but I took a quick look into
what changed with this commit for my laptop. Before the commit,
rps.min_freq_softlimit is 4 (from rps.min_freq) and
rps.max_freq_softlimit is 22.
After the commit, rps.min_freq_softlimit is set to the
rps.efficient_freq value read from pcode, which is 34 on my laptop.
So later when gen6_set_rps() is called with rps.min_freq_softlimit that
warning is hit.
Any thoughts? It certainly seems fishy that this commit causes
rps.min_freq_softlimit to be greater than rps.max_freq_softlimit.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
