<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - kms_frontbuffer_tracking - FBC disabled" href="https://bugs.freedesktop.org/show_bug.cgi?id=105359#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - kms_frontbuffer_tracking - FBC disabled" href="https://bugs.freedesktop.org/show_bug.cgi?id=105359">bug 105359</a> from <a class="email" href="mailto:marta.lofstedt@intel.com" title="Marta Löfstedt <marta.lofstedt@intel.com>"> Marta Löfstedt</a> <pre><a href="https://patchwork.freedesktop.org/patch/208170/">https://patchwork.freedesktop.org/patch/208170/</a> This caused some discussion. I appears as if devs want a way for user space to reset the "fbc state". I am assuming this also applies for FIFO underrun caused FBC disabled. I guess that is OK, the only one calling: intel_fbc_handle_fifo_underrun_irq(dev_priv); is: void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv, enum pipe pipe) However, this comment in above function: /* There's no guarantee that underrun_detected won't be set to true * right after this check and before the work is scheduled, but that's * not a problem since we'll check it again under the work function * while FBC is locked. This check here is just to prevent us from * unnecessarily scheduling the work, and it relies on the fact that we * never switch underrun_detect back to false after it's true. */ so maybe not totally straight forward to implement. Also, I believe that the massive hit from "FBC disabled" on kasan and shard testlist on BAT is due to this FBC banned by FIFO underrun thing.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>