kernel/linux.git/drivers/gpu, branch v4.9.4

drm/i915/gen9: Fix PCODE polling during CDCLK change notification

2017-01-15T12:42:57+00:00

commit 2c7d0602c815277f7cb7c932b091288710d8aba7 upstream. commit 848496e5902833600f7992f4faa82dc1546051ba Author: Ville Syrjälä Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at least one SKL. A CDCLK change request following the failed one will succeed nevertheless. I could reproduce this problem easily by running kms_pipe_crc_basic in a loop. In all failure cases _wait_for() was pre-empted for >3ms and so in the worst case - when the pre-emption happened right after calculating timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only once which failed and so _wait_for() timed out. As opposed to this the spec says to keep retrying the request for at most a 3ms period. To fix this send the first request explicitly to guarantee that there is 3ms between the first and last request. Though this matches the spec, I noticed that in rare cases this can still time out if we sent only a few requests (in the worst case 2) _and_ PCODE is busy for some reason even after a previous request and a 3ms delay. To work around this retry the polling with pre-emption disabled to maximize the number of requests. Also increase the timeout to 10ms to account for interrupts that could reduce the number of requests. With this change I couldn't trigger the problem. v2: - Use 1ms poll period instead of 10us. (Chris) v3: - Poll with pre-emption disabled to increase the number of request attempts. (Ville, Chris) - Factor out a helper to poll, it's also needed by the next patch. v4: - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the reply is generic. (Ville) v5: - List the request specific timeout values as code comment. (Ville) v6: - Try the poll first with preemption enabled. - Add code comment about first request being queued by PCODE. (Art) - Add timeout_base_ms argument. (Ville) v7: - Clarify code comment about first queued request. (Chris) Cc: Ville Syrjälä Cc: Chris Wilson Cc: Art Runyan Cc: # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms Cc: # v4.2- Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume") Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by: Imre Deak Reviewed-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com (cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd) Signed-off-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman

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