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

drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX

2019-08-29T06:30:22+00:00

commit c358ebf59634f06d8ed176da651ec150df3c8686 upstream.

While I had thought I had fixed this issue in:

commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")

It turns out that while I did fix the error messages I was seeing on my
P50 when trying to access i2c busses with the GPU in runtime suspend, I
accidentally had missed one important detail that was mentioned on the
bug report this commit was supposed to fix: that the CPU would only lock
up when trying to access i2c busses _on connected devices_ _while the
GPU is not in runtime suspend_. Whoops. That definitely explains why I
was not able to get my machine to hang with i2c bus interactions until
now, as plugging my P50 into it's dock with an HDMI monitor connected
allowed me to finally reproduce this locally.

Now that I have managed to reproduce this issue properly, it looks like
the problem is much simpler then it looks. It turns out that some
connected devices, such as MST laptop docks, will actually ACK i2c reads
even if no data was actually read:

[  275.063043] nouveau 0000:01:00.0: i2c: aux 000a: 1: 0000004c 1
[  275.063447] nouveau 0000:01:00.0: i2c: aux 000a: 00 01101000 10040000
[  275.063759] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000001
[  275.064024] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[  275.064285] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[  275.064594] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000

Because we don't handle the situation of i2c ack without any data, we
end up entering an infinite loop in nvkm_i2c_aux_i2c_xfer() since the
value of cnt always remains at 0. This finally properly explains how
this could result in a CPU hang like the ones observed in the
aforementioned commit.

So, fix this by retrying transactions if no data is written or received,
and give up and fail the transaction if we continue to not write or
receive any data after 32 retries.

Signed-off-by: Lyude Paul 
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible

2019-08-29T06:30:22+00:00

commit 98f58ada2d37e68125c056f1fc005748251879c2 upstream.

We need to set certain power gating flags after we determine
if the firmware version is sufficient to support gfxoff.
Previously we set the pg flags in early init, but we later
we might have disabled gfxoff if the firmware versions didn't
support it.  Move adding the additional pg flags after we
determine whether or not to support gfxoff.

Fixes: 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series (v2)")
Tested-by: Kai-Heng Feng 
Tested-by: Tom St Denis 
Signed-off-by: Alex Deucher 
Cc: Kai-Heng Feng 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: fix memory leak when too many retries have occurred

2019-08-29T06:30:18+00:00

[ Upstream commit 6b7c3b86f0b63134b2ab56508921a0853ffa687a ]

Currently when too many retries have occurred there is a memory
leak on the allocation for reply on the error return path. Fix
this by kfree'ing reply before returning.

Addresses-Coverity: ("Resource leak")
Fixes: a9cd9c044aa9 ("drm/vmwgfx: Add a check to handle host message failure")
Signed-off-by: Colin Ian King 
Reviewed-by: Deepak Rawat 
Signed-off-by: Deepak Rawat 
Signed-off-by: Thomas Hellstrom 
Signed-off-by: Sasha Levin

drm/amdgpu: pin the csb buffer on hw init for gfx v8

2019-08-29T06:30:16+00:00

[ Upstream commit 72cda9bb5e219aea0f2f62f56ae05198c59022a7 ]

Without this pin, the csb buffer will be filled with inconsistent
data after S3 resume. And that will causes gfx hang on gfxoff
exit since this csb will be executed then.

Signed-off-by: Likun Gao 
Tested-by: Paul Gover 
Reviewed-by: Feifei Xu 
Reviewed-by: Xiaojie Yuan 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/rockchip: Suspend DP late

2019-08-29T06:30:14+00:00

[ Upstream commit f7ccbed656f78212593ca965d9a8f34bf24e0aab ]

In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved
resume to be early but left suspend at its normal time.  This seems
like it could be OK, but casues problems if a suspend gets interrupted
partway through.  The OS only balances matching suspend/resume levels.
...so if suspend was called then resume will be called.  If suspend
late was called then resume early will be called.  ...but if suspend
was called resume early might not get called.  This leads to an
unbalance in the clock enables / disables.

Lets take the simple fix and just move suspend to be late to match.
This makes the PM core take proper care in keeping things balanced.

Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early")
Signed-off-by: Douglas Anderson 
Signed-off-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184616.44822-1-dianders@chromium.org
Signed-off-by: Sasha Levin

drm/exynos: fix missing decrement of retry counter

2019-08-25T14:10:33+00:00

[ Upstream commit 1bbbab097a05276e312dd2462791d32b21ceb1ee ]

Currently the retry counter is not being decremented, leading to a
potential infinite spin if the scalar_reads don't change state.

Addresses-Coverity: ("Infinite loop")
Fixes: 280e54c9f614 ("drm/exynos: scaler: Reset hardware before starting the operation")
Signed-off-by: Colin Ian King 
Signed-off-by: Inki Dae 
Signed-off-by: Sasha Levin

drm: msm: Fix add_gpu_components

2019-08-25T14:10:33+00:00

[ Upstream commit 9ca7ad6c7706edeae331c1632d0c63897418ebad ]

add_gpu_components() adds found GPU nodes from the DT to the match list,
regardless of the status of the nodes.  This is a problem, because if the
nodes are disabled, they should not be on the match list because they will
not be matched.  This prevents display from initing if a GPU node is
defined, but it's status is disabled.

Fix this by checking the node's status before adding it to the match list.

Fixes: dc3ea265b856 (drm/msm: Drop the gpu binding)
Reviewed-by: Rob Clark 
Signed-off-by: Jeffrey Hugo 
Signed-off-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20190626180015.45242-1-jeffrey.l.hugo@gmail.com
Signed-off-by: Sasha Levin

drm/amdgpu: fix a potential information leaking bug

2019-08-25T14:10:31+00:00

[ Upstream commit 929e571c04c285861e0bb049a396a2bdaea63282 ]

Coccinelle reports a path that the array "data" is never initialized.
The path skips the checks in the conditional branches when either
of callback functions, read_wave_vgprs and read_wave_sgprs, is not
registered. Later, the uninitialized "data" array is read
in the while-loop below and passed to put_user().

Fix the path by allocating the array with kcalloc().

The patch is simplier than adding a fall-back branch that explicitly
calls memset(data, 0, ...). Also it does not need the multiplication
1024*sizeof(*data) as the size parameter for memset() though there is
no risk of integer overflow.

Signed-off-by: Wang Xiayang 
Reviewed-by: Chunming Zhou 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amdgpu: fix error handling in amdgpu_cs_process_fence_dep

2019-08-25T14:10:30+00:00

[ Upstream commit 67d0859e2758ef992fd32499747ce4b1038a63c0 ]

We always need to drop the ctx reference and should check
for errors first and then dereference the fence pointer.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/amd/powerplay: fix null pointer dereference around dpm state relates

2019-08-25T14:10:30+00:00

[ Upstream commit 479156f2e5540077377a823eaf5a4263bd329063 ]

DPM state relates are not supported on the new SW SMU ASICs. But still
it's not OK to trigger null pointer dereference on accessing them.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin