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

drm: fb-helper: Reject all pixel format changing requests

2018-11-10T15:48:35+00:00

commit db05c481977599236f12a85e55de9f5ab37b0a2c upstream.

drm fbdev emulation doesn't support changing the pixel format at all,
so reject all pixel format changing requests.

Cc: stable@vger.kernel.org
Signed-off-by: Eugeniy Paltsev 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20181003164538.5534-1-Eugeniy.Paltsev@synopsys.com
Signed-off-by: Greg Kroah-Hartman

drm/edid: VSDB yCBCr420 Deep Color mode bit definitions

2018-11-10T15:48:35+00:00

commit 9068e02f58740778d8270840657f1e250a2cc60f upstream.

HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct
definitions in the header for the mask to work correctly.

Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893
Cc:  # v4.14+
Signed-off-by: Clint Taylor 
Reviewed-by: Jani Nikula 
Reviewed-by: Shashank Sharma 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/1538776335-12569-1-git-send-email-clinton.a.taylor@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl

2018-11-10T15:48:34+00:00

commit 0711a43b6d84ff9189adfbf83c8bbf56eef794bf upstream.

There's another panel that reports "DFP 1.x compliant TMDS" but it
supports 6bpc instead of 8 bpc.

Apply 6 bpc quirk for the panel to fix it.

BugLink: https://bugs.launchpad.net/bugs/1794387
Cc:  # v4.8+
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20181002152911.4370-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman

drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path

2018-11-04T13:52:48+00:00

commit ffdf16edfbbe77f5f5c3c87fe8d7387ecd16241b upstream

The error exit path when a duplicate is found does not kfree and cmd_entry
struct and hence there is a small memory leak.  Fix this by kfree'ing it.

Detected by CoverityScan, CID#1370198 ("Resource Leak")

Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
Signed-off-by: Colin Ian King 
Reviewed-by: Chris Wilson 
Signed-off-by: Zhenyu Wang 
Signed-off-by: Sudip Mukherjee 
Acked-by: Zhenyu Wang 
Signed-off-by: Sasha Levin

drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.

2018-10-20T07:48:53+00:00

commit 0ca9488193e61ec5f31a631d8147f74525629e8a upstream.

On GLK NUC platforms the HDMI retiming buffer needs additional disabled
time to correctly sync to a faster incoming signal.

When measured on a scope the highspeed lines of the HDMI clock turn off
 for ~400uS during a normal resolution change. The HDMI retimer on the
 GLK NUC appears to require at least a full frame of quiet time before a
new faster clock can be correctly sync'd. Wait 100ms due to msleep
inaccuracies while waiting for a completed frame. Add a quirk to the
driver for GLK boards that use ITE66317 HDMI retimers.

V2: Add more devices to the quirk list
V3: Delay increased to 100ms, check to confirm crtc type is HDMI.
V4: crtc type check extended to include _DDI and whitespace fixes
v5: Fix white spaces, remove the macro for delay. Revert the crtc type
    check introduced in v4.

Cc: Imre Deak 
Cc:  # v4.14+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
Signed-off-by: Clint Taylor 
Tested-by: Daniel Scheller 
Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Imre Deak 
Reviewed-by: Imre Deak 
Link: https://patchwork.freedesktop.org/patch/msgid/20180710200205.1478-1-radhakrishna.sripada@intel.com
(cherry picked from commit 90c3e2198777aaa355b6994a31a79c636c8d4306)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Nuke the LVDS lid notifier

2018-10-20T07:48:53+00:00

commit 05c72e77ccda89ff624108b1b59a0fc43843f343 upstream.

We broke the LVDS notifier resume thing in (presumably) commit
e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") as
we no longer duplicate the current state in the LVDS notifier and
thus we never resume it properly either.

Instead of trying to fix it again let's just kill off the lid
notifier entirely. None of the machines tested thus far have
apparently needed it. Originally the lid notifier was added to
work around cases where the VBIOS was clobbering some of the
hardware state behind the driver's back, mostly on Thinkpads.
We now have a few report of Thinkpads working just fine without
the notifier. So maybe it was misdiagnosed originally, or
something else has changed (ACPI video stuff perhaps?).

If we do end up finding a machine where the VBIOS is still causing
problems I would suggest that we first try setting various bits in
the VBIOS scratch registers. There are several to choose from that
may instruct the VBIOS to steer clear.

With the notifier gone we'll also stop looking at the panel status
in ->detect().

v2: Nuke enum modeset_restore (Rodrigo)

Cc: stable@vger.kernel.org
Cc: Wolfgang Draxinger 
Cc: Vito Caputo 
Cc: kitsunyan 
Cc: Joonas Saarinen 
Tested-by: Vito Caputo  # Thinkapd X61s
Tested-by: kitsunyan  # ThinkPad X200
Tested-by: Joonas Saarinen  # Fujitsu Siemens U9210
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105902
References: https://lists.freedesktop.org/archives/intel-gfx/2018-June/169315.html
References: https://bugs.freedesktop.org/show_bug.cgi?id=21230
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

drm: mali-dp: Call drm_crtc_vblank_reset on device init

2018-10-20T07:48:51+00:00

[ Upstream commit 69be1984ded00a11b1ed0888c6d8e4f35370372f ]

Currently, if userspace calls drm_wait_vblank before the crtc is
activated the crtc vblank_enable hook is called, which in case of
malidp driver triggers some warninngs. This happens because on
device init we don't inform the drm core about the vblank state
by calling drm_crtc_vblank_on/off/reset which together with
drm_vblank_get have some magic that prevents calling drm_vblank_enable
when crtc is off.

Signed-off-by: Alexandru Gheorghe 
Acked-by: Liviu Dudau 
Signed-off-by: Liviu Dudau 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7

2018-10-18T07:16:23+00:00

[ Upstream commit caaa4c8a6be2a275bd14f2369ee364978ff74704 ]

A wrong register bit was examinated for checking SDMA status so it reports
false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct
bit.

Acked-by: Alex Deucher 
Signed-off-by: Amber Lin 
Reviewed-by: Felix Kuehling 
Signed-off-by: Felix Kuehling 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/syncobj: Don't leak fences when WAIT_FOR_SUBMIT is set

2018-10-13T07:27:23+00:00

commit 337fe9f5c1e7de1f391c6a692531379d2aa2ee11 upstream.

We attempt to get fences earlier in the hopes that everything will
already have fences and no callbacks will be needed.  If we do succeed
in getting a fence, getting one a second time will result in a duplicate
ref with no unref.  This is causing memory leaks in Vulkan applications
that create a lot of fences; playing for a few hours can, apparently,
bring down the system.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107899
Reviewed-by: Chris Wilson 
Signed-off-by: Jason Ekstrand 
Signed-off-by: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20180926071703.15257-1-jason.ekstrand@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix vce work queue was not cancelled when suspend

2018-10-13T07:27:23+00:00

commit 61ea6f5831974ebd1a57baffd7cc30600a2e26fc upstream.

The vce cancel_delayed_work_sync never be called.
driver call the function in error path.

This caused the A+A suspend hang when runtime pm enebled.
As we will visit the smu in the idle queue. this will cause
smu hang because the dgpu has been suspend, and the dgpu also
will be waked up. As the smu has been hang, so the dgpu resume
will failed.

Reviewed-by: Christian König 
Reviewed-by: Feifei Xu 
Signed-off-by: Rex Zhu 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman