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

drm/vmwgfx/ldu: Use drm_mode_config_reset

2020-09-03T09:29:51+00:00

commit 981243371a5d832af5bc572071172e955d02fe88 upstream.

Same problem as in stdu, same fix.

Fixes: 51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset")
Acked-by: Charmaine Lee 
Reviewed-by: Zack Rusin 
Signed-off-by: Roland Scheidegger 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx/sou: Use drm_mode_config_reset

2020-09-03T09:29:51+00:00

commit 1338441cf166e2ef789af5915b961d4e13a4ec31 upstream.

Same problem as in stdu, same fix.

Fixes: 51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset")
Acked-by: Charmaine Lee 
Reviewed-by: Zack Rusin 
Signed-off-by: Roland Scheidegger 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx/stdu: Use drm_mode_config_reset

2020-09-03T09:29:51+00:00

commit 68745d1edf1700a668c15ecbed466d18f14c7e9b upstream.

When converting to atomic the state reset was done by directly calling
the functions, and before the modeset object was fully initialized.
This means the various ->dev pointers weren't set up.

After

commit 51f644b40b4b794b28b982fdd5d0dd8ee63f9272
Author: Daniel Vetter 
Date:   Fri Jun 12 18:00:49 2020 +0200

    drm/atomic-helper: reset vblank on crtc reset

this started to oops because now we're trying to derefence
drm_crtc->dev. Fix this up by entirely switching over to
drm_mode_config_reset, called once everything is set up.

Fixes: 51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset")
Reported-by: Tetsuo Handa 
Cc: Tetsuo Handa 
Signed-off-by: Daniel Vetter 
Tested-by: Roland Scheidegger 
Signed-off-by: Roland Scheidegger 
Signed-off-by: Greg Kroah-Hartman

drm/atomic-helper: reset vblank on crtc reset

2020-09-03T09:29:50+00:00

[ Upstream commit 51f644b40b4b794b28b982fdd5d0dd8ee63f9272 ]

Only when vblanks are supported ofc.

Some drivers do this already, but most unfortunately missed it. This
opens up bugs after driver load, before the crtc is enabled for the
first time. syzbot spotted this when loading vkms as a secondary
output. Given how many drivers are buggy it's best to solve this once
and for all in shared helper code.

Aside from moving the few existing calls to drm_crtc_vblank_reset into
helpers (i915 doesn't use helpers, so keeps its own) I think the
regression risk is minimal: atomic helpers already rely on drivers
calling drm_crtc_vblank_on/off correctly in their hooks when they
support vblanks. And driver that's failing to handle vblanks after
this is missing those calls already, and vblanks could only work by
accident when enabling a CRTC for the first time right after boot.

Big thanks to Tetsuo for helping track down what's going wrong here.

There's only a few drivers which already had the necessary call and
needed some updating:
- komeda, atmel and tidss also needed to be changed to call
  __drm_atomic_helper_crtc_reset() intead of open coding it
- tegra and msm even had it in the same place already, just code
  motion, and malidp already uses __drm_atomic_helper_crtc_reset().
- Laurent noticed that rcar-du and omap open-code their crtc reset and
  hence would actually be broken by this patch now. So fix them up by
  reusing the helpers, which brings the drm_crtc_vblank_reset() back.

Only call left is in i915, which doesn't use drm_mode_config_reset,
but has its own fastboot infrastructure. So that's the only case where
we actually want this in the driver still.

I've also reviewed all other drivers which set up vblank support with
drm_vblank_init. After the previous patch fixing mxsfb all atomic
drivers do call drm_crtc_vblank_on/off as they should, the remaining
drivers are either legacy kms or legacy dri1 drivers, so not affected
by this change to atomic helpers.

v2: Use the drm_dev_has_vblank() helper.

v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
instead of drm_crtc_vblank_reset. Adjust them too.

v4: Laurent noticed that rcar-du and omap open-code their crtc reset
and hence would actually be broken by this patch now. So fix them up
by reusing the helpers, which brings the drm_crtc_vblank_reset() back.

v5: also mention rcar-du and ompadrm in the proper commit message
above (Laurent).

Reviewed-by: Laurent Pinchart 
Acked-by: Maxime Ripard 
Cc: Laurent Pinchart 
Reviewed-by: Boris Brezillon 
Acked-by: Liviu Dudau 
Acked-by: Thierry Reding 
Link: https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
Reported-by: Tetsuo Handa 
Reported-by: syzbot+0871b14ca2e2fb64f6e3@syzkaller.appspotmail.com
Cc: Tetsuo Handa 
Cc: "James (Qian) Wang" 
Cc: Liviu Dudau 
Cc: Mihail Atanassov 
Cc: Brian Starkey 
Cc: Sam Ravnborg 
Cc: Boris Brezillon 
Cc: Nicolas Ferre 
Cc: Alexandre Belloni 
Cc: Ludovic Desroches 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: Rob Clark 
Cc: Sean Paul 
Cc: Brian Masney 
Cc: Emil Velikov 
Cc: zhengbin 
Cc: Thomas Gleixner 
Cc: linux-tegra@vger.kernel.org
Cc: Kieran Bingham 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20200612160056.2082681-1-daniel.vetter@ffwll.ch
Signed-off-by: Sasha Levin

drm/amd/pm: correct the thermal alert temperature limit settings

2020-09-03T09:29:47+00:00

commit 28e628645333b7e581c4a7b04d958e4804ea10fe upstream.

Do the maths in celsius degree. This can fix the issues caused
by the changes below:

drm/amd/pm: correct Vega20 swctf limit setting
drm/amd/pm: correct Vega12 swctf limit setting
drm/amd/pm: correct Vega10 swctf limit setting

Signed-off-by: Evan Quan 
Reviewed-by: Kenneth Feng 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/pm: correct Vega20 swctf limit setting

2020-09-03T09:29:47+00:00

commit 9b51c4b2ba31396f3894ccc7df8bdf067243e9f5 upstream.

Correct the Vega20 thermal swctf limit.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/pm: correct Vega12 swctf limit setting

2020-09-03T09:29:46+00:00

commit e0ffd340249699ad27a6c91abdfa3e89f7823941 upstream.

Correct the Vega12 thermal swctf limit.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/pm: correct Vega10 swctf limit setting

2020-09-03T09:29:46+00:00

commit b05d71b51078fc428c6b72582126d9d75d3c1f4c upstream.

Correct the Vega10 thermal swctf limit.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1267

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amd/powerplay: Fix hardmins not being sent to SMU for RV

2020-09-03T09:29:46+00:00

commit e2bf3723db563457c0abe4eaeedac25bbbbd1d76 upstream.

[Why]
DC uses these to raise the voltage as needed for higher dispclk/dppclk
and to ensure that we have enough bandwidth to drive the displays.

There's a bug preventing these from actuially sending messages since
it's checking the actual clock (which is 0) instead of the incoming
clock (which shouldn't be 0) when deciding to send the hardmin.

[How]
Check the clocks != 0 instead of the actual clocks.

Fixes: 9ed9203c3ee7 ("drm/amd/powerplay: rv dal-pplib interface refactor powerplay part")
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Alex Deucher 
Reviewed-by: Evan Quan 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/gfx10: refine mgcg setting

2020-09-03T09:29:46+00:00

commit de7a1b0b8753e1b0000084f0e339ffab295d27ef upstream.

1. enable ENABLE_CGTS_LEGACY to fix specviewperf11 random hang.
2. remove obsolete RLC_CGTT_SCLK_OVERRIDE workaround.

Signed-off-by: Jiansong Chen 
Reviewed-by: Hawking Zhang 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman