linux-stable.git/drivers/gpu/drm, branch v5.6.8

drm/i915/gt: Update PMINTRMSK holding fw

2020-04-29T14:34:57+00:00

commit e1eb075c5051987fbbadbc0fb8211679df657721 upstream.

If we use a non-forcewaked write to PMINTRMSK, it does not take effect
until much later, if at all, causing a loss of RPS interrupts and no GPU
reclocking, leaving the GPU running at the wrong frequency for long
periods of time.

Reported-by: Francisco Jerez 
Suggested-by: Francisco Jerez 
Fixes: 35cc7f32c298 ("drm/i915/gt: Use non-forcewake writes for RPS")
Signed-off-by: Chris Wilson 
Cc: Francisco Jerez 
Cc: Mika Kuoppala 
Cc: Andi Shyti 
Reviewed-by: Mika Kuoppala 
Reviewed-by: Andi Shyti 
Reviewed-by: Francisco Jerez 
Cc:  # v5.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20200415170318.16771-2-chris@chris-wilson.co.uk
(cherry picked from commit a080bd994c4023042a2b605c65fa10a25933f636)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Greg Kroah-Hartman

drm/dp_mst: Zero assigned PBN when releasing VCPI slots

2020-04-29T14:34:49+00:00

commit 7bfc1fec1af3e2f0194843855b0d49054fa42fd2 upstream.

Zero Port's PBN together with VCPI slots when releasing
allocated VCPI slots. That way when disabling the connector
it will not cause issues in drm_dp_mst_atomic_check verifying
branch bw limit.

Signed-off-by: Mikita Lipski 
Signed-off-by: Lyude Paul 
Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
Cc:  # v5.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20200407160717.27976-1-mikita.lipski@amd.com
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Calculate scaling ratios on every medium/full update

2020-04-29T14:34:34+00:00

[ Upstream commit 3bae20137cae6c03f58f96c0bc9f3d46f0bc17d4 ]

[Why]
If a plane isn't being actively enabled or disabled then DC won't
always recalculate scaling rects and ratios for the primary plane.

This results in only a partial or corrupted rect being displayed on
the screen instead of scaling to fit the screen.

[How]
Add back the logic to recalculate the scaling rects into
dc_commit_updates_for_stream since this is the expected place to
do it in DC.

This was previously removed a few years ago to fix an underscan issue
but underscan is still functional now with this change - and it should
be, since this is only updating to the latest plane state getting passed
in.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Aric Cyr 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/display: Update stream adjust in dc_stream_adjust_vmin_vmax

2020-04-29T14:34:28+00:00

[ Upstream commit 346d8a0a3c91888a412c2735d69daa09c00f0203 ]

[Why]
After v_total_min and max are updated in vrr structure, the changes are
not reflected in stream adjust. When these values are read from stream
adjust it does not reflect the actual state of the system.

[How]
Set stream adjust values equal to vrr adjust values after vrr adjust
values are updated.

Signed-off-by: Isabel Zhang 
Reviewed-by: Alvin Lee 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during init

2020-04-23T08:38:22+00:00

[ Upstream commit 028a12f5aa829b4ba6ac011530b815eda4960e89 ]

Certain boards with GP107/GP108 chipsets hang (often, but randomly) for
unknown reasons during GR initialisation.

The first tell-tale symptom of this issue is:

nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ]

appearing in dmesg, likely followed by many other failures being logged.

Karol found this WAR for the issue a while back, but efforts to isolate
the root cause and proper fix have not yielded success so far.  I've
modified the original patch to include a few more details, limit it to
GP107/GP108 by default, and added a config option to override this choice.

Signed-off-by: Ben Skeggs 
Reviewed-by: Karol Herbst 
Signed-off-by: Sasha Levin

drm/vc4: Fix HDMI mode validation

2020-04-23T08:38:17+00:00

[ Upstream commit b1e7396a1d0e6af6806337fdaaa44098d6b3343c ]

Current mode validation impedes setting up some video modes which should
be supported otherwise. Namely 1920x1200@60Hz.

Fix this by lowering the minimum HDMI state machine clock to pixel clock
ratio allowed.

Fixes: 32e823c63e90 ("drm/vc4: Reject HDMI modes with too high of clocks.")
Reported-by: Stefan Wahren 
Suggested-by: Dave Stevenson 
Signed-off-by: Nicolas Saenz Julienne 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20200326122001.22215-1-nsaenzjulienne@suse.de
Signed-off-by: Sasha Levin

drm/amdkfd: kfree the wrong pointer

2020-04-23T08:38:14+00:00

[ Upstream commit 3148a6a0ef3cf93570f30a477292768f7eb5d3c3 ]

Originally, it kfrees the wrong pointer for mem_obj.
It would cause memory leak under stress test.

Signed-off-by: Jack Zhang 
Acked-by: Nirmoy Das 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges

2020-04-23T08:38:14+00:00

[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]

Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.

Depending on the used kernel there might be messages like those in demsg:

"nouveau 0000:01:00.0: Refused to change power state, currently in D3"
"nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.

It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.

Signed-off-by: Karol Herbst 
Cc: Bjorn Helgaas 
Cc: Lyude Paul 
Cc: Rafael J. Wysocki 
Cc: Mika Westerberg 
Cc: linux-pci@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin

drm/nouveau/svm: fix vma range check for migration

2020-04-23T08:38:13+00:00

[ Upstream commit b92103b559c77abc5f8b7bec269230a219c880b7 ]

find_vma_intersection(mm, start, end) only guarantees that end is greater
than or equal to vma->vm_start but doesn't guarantee that start is
greater than or equal to vma->vm_start. The calculation for the
intersecting range in nouveau_svmm_bind() isn't accounting for this and
can call migrate_vma_setup() with a starting address less than
vma->vm_start. This results in migrate_vma_setup() returning -EINVAL for
the range instead of nouveau skipping that part of the range and migrating
the rest.

Signed-off-by: Ralph Campbell 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin

drm/nouveau/svm: check for SVM initialized before migrating

2020-04-23T08:38:12+00:00

[ Upstream commit 822cab6150d3002952407a8297ff5a0d32bb7b54 ]

When migrating system memory to GPU memory, check that SVM has been
enabled. Even though most errors can be ignored since migration is
a performance optimization, return an error because this is a violation
of the API.

Signed-off-by: Ralph Campbell 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin