linux-stable.git/drivers/gpu, branch v4.9.3

drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

2017-01-12T10:39:38+00:00

commit 2ef32dee97fcf41987722a37eb6ff1a983915e99 upstream.

The previous spec version said "double Ytile planes minimum lines",
and I interpreted this as referring to what the spec calls "Y tile
minimum", but in fact it was referring to what the spec calls "Minimum
Scanlines for Y tile". I noticed that Mahesh Kumar had a different
interpretation, so I sent and email to the spec authors and got
clarification on the correct meaning. Also, BSpec was updated and
should be clear now.

Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the memory bandwidth WA")
Cc: stable@vger.kernel.org
Cc: Mahesh Kumar 
Signed-off-by: Paulo Zanoni 
Reviewed-by: Matt Roper 
Link: http://patchwork.freedesktop.org/patch/msgid/1478636531-6081-1-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/i915/gen9: unconditionally apply the memory bandwidth WA

2017-01-12T10:39:38+00:00

commit ee3d532fcb64872bc20be0ee58f7afdb9fa82abe upstream.

Mahesh Kumar is already working on a proper implementation for the
workaround, but while we still don't have it, let's just
unconditionally apply the workaround for everybody and we hope we can
close all those numerous bugzilla tickets. Also, I'm not sure how easy
it will be to backport the final implementation to the stable Kernels,
and this patch here is probably easier to backport.

At the present moment I still don't have confirmation that this patch
fixes any of the bugs listed below, but we should definitely try
testing all of them again.

v2: s/intel_needs_memory_bw_wa/skl_needs_memory_bw_wa/ (Lyude).
v3: Rebase (dev -> dev_priv change on ilk_wm_max_level).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94337
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94884
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95010
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97830
Cc: Mahesh Kumar 
Cc: Lyude 
Cc: Dhinakaran Pandiyan 
Signed-off-by: Paulo Zanoni 
Reviewed-by: Lyude 
Link: http://patchwork.freedesktop.org/patch/msgid/1476210338-9797-1-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/i915: disable PSR by default on HSW/BDW

2017-01-12T10:39:38+00:00

commit 1c4672ce4eeaeaadeea8adabaad21262b7172607 upstream.

We've been ignoring the poor bugzilla reporters that say PSR causes
system lockups and all other sorts of problems. The earliest bug
report is from April, so I think we can use the "revert the offending
commit if no fixes are presented within 8 months" rule here.

Fixes: 9b58e352b463 ("drm/i915: Enable PSR by default on Haswell and Broadwell.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97602
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97515
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96736
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96704
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96569
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94985
Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Paulo Zanoni 
Acked-by: Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi 
Acked-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/1481662664-18986-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 2ee7dc497e348eecbb82adbb1ea9e9a7e29fe921)
Signed-off-by: Jani Nikula 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Always store CRTC relative radeon_crtc->cursor_x/y values

2017-01-12T10:39:38+00:00

commit 4349bd775cc8fd75cb648e3a2036a690f497de5c upstream.

We were storing viewport relative coordinates for AVIVO/DCE display
engines. However, radeon_crtc_cursor_set2 and radeon_cursor_reset pass
radeon_crtc->cursor_x/y as the x/y parameters of
radeon_cursor_move_locked, which would break if the CRTC isn't located
at (0, 0).

Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: tune down the fast link training vs boot fail

2017-01-12T10:39:22+00:00

commit 2c57b18adb93fc070039538f1ce375d3d3e99bbb upstream.

It's been unfixed since a while and no one is immediately working on
this. And we have the FIXME already. And now also a task in the DP
team's backlog.

Cc: Linus Torvalds 
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä 
References: https://lists.freedesktop.org/archives/intel-gfx/2016-July/101951.html
Acked-by: Ville Syrjälä 
[danvet: Adjust comment per Ville's feedback.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20161213195414.28923-1-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman 

(cherry picked from commit 2dd85aeb5bc99e3763dd192cdb95ff405a102c8a)
Signed-off-by: Jani Nikula

drm/i915/dp: add lane_count check in intel_dp_check_link_status

2017-01-12T10:39:22+00:00

commit d4cb3fd9b548b8bfe2a712ec920b9ebabd3547ab upstream.

Currently it's entirely possible to go through the link training step
without first determining the lane_count, which is silly since we end up
doing a bunch of aux transfers of size = 0, as highlighted by
WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
'failed to update link training' message. This can be observed during
intel_dp_long_pulse where we can do the link training step, but before
we have had a chance to set the link params. To avoid this we add an
extra check for the lane_count in intel_dp_check_link_status, which
should prevent us from doing the link training step prematurely.

v2: add WARN_ON_ONCE and FIXME comment (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
Cc: Ville Syrjälä 
Cc: Mika Kahola 
Signed-off-by: Matthew Auld 
Link: http://patchwork.freedesktop.org/patch/msgid/1476912593-10019-1-git-send-email-matthew.auld@intel.com
Signed-off-by: Ville Syrjälä 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Initialize overlay->last_flip properly

2017-01-12T10:39:08+00:00

commit a6d3e7d35d088b2aabad1688b740e17bfdf566c5 upstream.

Initialize overlay->last_flip properly instead of leaving it zeroed.

Cc: Chris Wilson 
Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
Reviewed-by: Chris Wilson 
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20161221144547.27319-1-ville.syrjala@linux.intel.com
(cherry picked from commit 330afdb1df0f3fb48583105493a8f4f8d9e3af36)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Force VDD off on the new power seqeuencer before starting to use it

2017-01-12T10:39:08+00:00

commit 8581f1b5ee0837e55197f036406bc99746ac94b2 upstream.

Apparently some VLV BIOSen like to leave the VDD force bit enabled
even for power seqeuncers that aren't properly hooked up to any
port. That will result in a imbalance in the AUX power domain
refcount when we stat to use said power sequencer as edp_panel_vdd_on()
will not grab the power domain reference if it sees that the VDD is
already on.

To fix this let's make sure we turn off the VDD force bit when we
initialize the power sequencer registers. That is, unless it's
being done from the init path since there we are actually
initializing the registers for the current power sequencer and
we don't want to turn VDD off needlessly as that would require
waiting for the power cycle delay before we turn it back on.

This fixes the following kind of warnings:
WARNING: CPU: 0 PID: 123 at ../drivers/gpu/drm/i915/intel_runtime_pm.c:1455 intel_display_power_put+0x13a/0x170 [i915]()
WARN_ON(!power_domains->domain_use_count[domain])
...

v2: Fix typos in comment (David)

Cc: Matwey V. Kornilov 
Tested-by: Matwey V. Kornilov 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98695
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20161220165117.24801-1-ville.syrjala@linux.intel.com
Reviewed-by: David Weinehall 
(cherry picked from commit 5d5ab2d26f32bdaa5872b938658e0bf8d341bc4c)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix oops in overlay due to frontbuffer tracking

2017-01-12T10:39:08+00:00

commit 9169757ae67bc927750ae907624e65cc15b4fe5a upstream.

The vma will be NULL if the overlay was previously off, so
dereferencing it will oops. Check for NULL before doing that.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Fixes: 9b3b7841b86d ("drm/i915/overlay: Use VMA as the primary tracker for images")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1481131693-27993-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson 
(cherry picked from commit 4a15cdbbc55463e55a7cdcf33f84ccc742ca9c29)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix oopses in the overlay code due to i915_gem_active stuff

2017-01-12T10:39:07+00:00

commit b72eb5ffa6d8601d9ba72619d75fb5b27723743a upstream.

The i915_gem_active stuff doesn't like a NULL ->retire hook, but
the overlay code can set it to NULL. That obviously ends up oopsing.
Fix it by introducing a new helper to assign the retirement callback
that will switch out the NULL function pointer with
i915_gem_retire_noop.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Fixes: 0d9bdd886f29 ("drm/i915: Convert intel_overlay to request tracking")
Signed-off-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Link: http://patchwork.freedesktop.org/patch/msgid/20161207175647.10018-1-chris@chris-wilson.co.uk
(cherry picked from commit ecd9caa0522db5a6b03ac8858c42067ef9d8323b)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman