[Bug 107588] [CI][BAT] igt at gem_exec_suspend@basic-S3 RPM wakelock ref not held during HW access RIP: 0010:gen5_read32

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jan 16 09:11:37 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=107588

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Martin Peres <martin.peres at free.fr> ---
(In reply to Chris Wilson from comment #6)
> commit 4a8ab5ea0cde753b03bfefe4c98a8c4c61f46550
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Mon Jan 14 14:21:29 2019 +0000
> 
>     drm/i915: Mark up Ironlake ips with rpm wakerefs
>     
>     Currently Ironlake operates under the assumption that rpm awake (and its
>     error checking is disabled). As such, we have missed a few places where
> we
>     access registers without taking the rpm wakeref and thus trigger
>     warnings. intel_ips being one culprit.
>     
>     As this involved adding a potentially sleeping rpm_get, we have to
>     rearrange the spinlocks slightly and so switch to acquiring a device-ref
>     under the spinlock rather than hold the spinlock for the whole
>     operation. To be consistent, we make the change in pattern common to the
>     intel_ips interface even though this adds a few more atomic operations
>     than necessary in a few cases.
>     
>     v2: Sagar noted the mb around setting mch_dev were overkill as we only
>     need ordering there, and that i915_emon_status was still using
>     struct_mutex for no reason, but lacked rpm.
>     
>     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>     Cc: Jani Nikula <jani.nikula at intel.com>
>     Reviewed-by: John Harrison <John.C.Harrison at Intel.com>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-21-
> chris at chris-wilson.co.uk

Thanks, it did the trick!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190116/ff5d9449/attachment.html>


More information about the intel-gfx-bugs mailing list