[Intel-gfx] i915: WARN_ON(val > dev_priv->rps.max_freq_softlimit)

[Michael Auchter]

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 at intel.com>
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 at intel.com>
    Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
    [danvet: Remove unused variables.]
    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>

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.