kernel.git/drivers/gpu/drm/i915/intel_fbc.c, branch linux-4.7.y

drm/i915/fbc: Disable on HSW by default for now

2016-06-21T16:45:21Z

>From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : This was kind of a difficult bug to track down. If you're using a Haswell system running GNOME and you have fbc completely enabled and working, playing videos can result in video artifacts. Steps to reproduce: - Run GNOME - Ensure FBC is enabled and active - Download a movie, I used the ogg version of Big Buck Bunny for this - Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin ! glimagesink` in a terminal - Watch for about over a minute, you'll see small horizontal lines go down the screen. For the time being, disable FBC for Haswell by default. Stefan Richter reported kernel freezes (no video artifacts) when fbc is on. (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE applications, thread begins at https://lkml.org/lkml/2016/4/26/813). We also got reports from Steven Honeyman on openbox+roxterm. v2 (From Paulo): - Add extra information to the commit message - Add Fixes tag - Rebase Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464 Fixes: a98ee79317b4 ("drm/i915/fbc: enable FBC by default on HSW and BDW") Cc: stable@vger.kernel.org Reviewed-by: Paulo Zanoni Signed-off-by: Lyude Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1465487895-7401-1-git-send-email-cpaul@redhat.com (cherry picked from commit c7f7e2feffb0294302041507dfd5fc15f01afccc) Signed-off-by: Jani Nikula

drm/i915: Refer to GGTT {,VM} consistently

2016-03-31T14:55:43Z

Refer to the GGTT VM consistently as "ggtt->base" instead of just "ggtt", "vm" or indirectly through other variables like "dev_priv->ggtt.base" to avoid confusion with the i915_ggtt object itself and PPGTT VMs. Refer to the GGTT as "ggtt" instead of indirectly through chaining. As a bonus gets rid of the long-standing i915_obj_to_ggtt vs. i915_gem_obj_to_ggtt conflict, due to removal of i915_obj_to_ggtt! v2: - Added some more after grepping sources with Chris v3: - Refer to GGTT VM through ggtt->base consistently instead of ggtt_vm (Chris) v4: - Convert all dev_priv->ggtt->foo accesses to ggtt->foo. v5: - Make patch checker happy Cc: Tvrtko Ursulin Cc: Mika Kuoppala Cc: Chris Wilson Signed-off-by: Joonas Lahtinen Reviewed-by: Chris Wilson

drm/i915: Rename dev_priv->gtt to dev_priv->ggtt

2016-03-18T13:18:15Z

Refer to Global GTT consistently as GGTT, thus rename dev_priv->gtt to dev_priv->ggtt and struct i915_gtt to struct i915_ggtt. Fix a couple of whitespace problems while at it. v2: - Fix a typo in commit message. Reviewed-by: Chris Wilson Signed-off-by: Joonas Lahtinen

drm/i915/fbc: enable FBC by default on HSW and BDW

2016-02-19T20:06:16Z

These platforms should be fine now. FBC can allow very significant power savings for screen-on idle systems, but it is worth mentioning that a lot of people won't get significant power savings by enabling this feature because they may have something else preventing the system from getting into the deepest sleep states. Examples may include a hungry wifi device or a max_performance SATA link power management policy. You can check your PC state residencies on the powertop "Idle stats" tab. I recommend trying to run "sudo powertop --auto-tune" and then seeing if the residencies improve. Oh, and in case you - the person reading this commit message - found this commit through git bisect, please do the following: - Check your dmesg and see if there are error messages mentioning underruns around the time your problem started happening. - Download intel-gpu-tools, compile it, and run: $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee fbc.txt Then send us the fbc.txt file, especially if you get a failure. This will really maximize your chances of getting the bug fixed quickly. - Try to find a reliable way to reproduce the problem, and tell us. - Boot with drm.debug=0xe, reproduce the problem, then send us the dmesg file. v2: Don't enable by default on SKL. Signed-off-by: Paulo Zanoni Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1455655643-2535-1-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: set fbc->active from the new activation functions

2016-02-04T16:18:22Z

Now that we have top-level gen-independent hw_activate and hw_deactivate functions, set fbc->active directly from them, removing the duplicated code. Reviewed-by: Maarten Lankhorst Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1454101060-23198-3-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: unexport the HW level activation functions

2016-02-04T16:17:45Z

The recent introduction of a new caller of dev_priv->fbc.deactivate() is a good example of why we need unexport those functions. Anything outside intel_fbc.c should only call the functions exported by intel_fbc.c, so in order to enforce that, kill the function pointers stored inside dev_priv->fbc and replace them with functions that can't be called from outside intel_fbc.c. This should make it much harder for new code to call these functions from outside intel_fbc.c. Reviewed-by: Maarten Lankhorst Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1454101060-23198-2-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: refactor some small functions called only once

2016-01-29T20:21:10Z

The FBC fixes we've been doing in the last months required a lot of refactor, so functions that were once big and called from different spots are now small and called only once. IMHO now it's better to just move the contents of these functions to their only callers since this reduces the number of indirections while reading the code. While at it, also improve the related comments a little bit. Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-26-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: don't store/check a pointer to the FB

2016-01-29T20:20:39Z

We already make sure we run intel_fbc_update_update during modesets and page flips, and this function takes care of deactivating FBC, so it shouldn't be possible for us to reach the condition we check at intel_fbc_work_fn. So instead of grabbing framebuffer references and adding a lot of code to track when we need to free them, just don't track anything at all since we shouldn't need to. v2: Rebase. Reviewed-by: Maarten Lankhorst Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-25-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: don't store the fb_id on reg_params

2016-01-29T20:18:28Z

We don't actually use fb_id anywhere. We already compare all parameters that matter to the hardware: pixel format, stride, fence_reg and ggtt_offset. The ID shouldn't make a difference. Besides, we already update the FBC data at every modeset/flip, so this can't change behind our backs. Reviewed-by: Maarten Lankhorst Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-23-git-send-email-paulo.r.zanoni@intel.com

drm/i915/fbc: don't print no_fbc_reason to dmesg

2016-01-29T20:18:16Z

Our dmesg messages started being misleading after we converted to the enable+activate model: we always print "Disabling FBC", even when we're just deactivating it. So, for example, when I boot my machine and do "dmesg | grep -i fbc", I see: [drm:intel_fbc_enable] Enabling FBC on pipe A [drm:set_no_fbc_reason] Disabling FBC: framebuffer not tiled or fenced but then, if I read the debugfs file, I will see: $ sudo cat i915_fbc_status FBC enabled Compressing: yes so we can conclude that dmesg is misleading, since FBC is actually enabled. What happened is that we deactivated FBC due to fbcon not being tiled, but when we silently reactivated it when the display manager started. We don't print activation messages since there may be way too many of these operations per second during normal desktop usage. One possible solution would be to change set_no_fbc_reason to correctly differentiate between disable and deactivation, but we removed support from printing activation/deactivation messages in the past because they were too frequent. So instead of doing this, let's just not print anything on dmesg, and leave the debugfs file if the user needs to investigate something. We already print when we enable and disable FBC anyway on a given pipe, so this should already help triaging bugs. Reviewed-by: Maarten Lankhorst Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-22-git-send-email-paulo.r.zanoni@intel.com