[Intel-gfx] [PATCH] tests/pm_rps: Add a new testcase to provoke the "stuck at max" bug

[Daniel Vetter]

Actually cc'ing Deepak might help.
-Daniel

On Thu, Mar 27, 2014 at 8:45 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> On Thu, Mar 27, 2014 at 3:19 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> On Wed, Mar 26, 2014 at 10:17:51PM +0100, Daniel Vetter wrote:
>>> Note that the sleep(5); to fully idle the gpu is _really_ important.
>>> Without it the bug is not exhibited.
>>>
>>> The issue at hand is that after gem_quiescent_gpu we are at max
>>> (expected, since the blocking waits peg to max), but then we never go
>>> down to a lower freq again until we're fully idle. The tiny load is
>>> sufficient to keep the gpu at max. I've played around with this a bit
>>> and even ridiculously low loads (like one MI_STORE per 50ms) are
>>> enough to keep the gpu at max freq.
>>
>> commit 2754436913b94626a5414d82f0996489628c513d
>> Author: Deepak S <deepak.s at intel.com>
>> Date:   Mon Jan 27 21:35:05 2014 +0530
>>
>>     drm/i915: Disable/Enable PM Intrrupts based on the current freq.
>>
>> as expected is complete and utter codswallop.
>
> I can confirm that reverting this plus it's vlv deps gets
> igt/pm_rps/blocking going again. The gpu isn't pegged to max any more
> like with current -nightly.
>
> Deepak? I guess this might explain why the boost logic gives sometimes
> inferior power numbers ... Note: Since this is a regression it counts
> as high-prio for upstream business ;-)
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch