linux-toradex.git/drivers/gpu, branch v4.9.35

drm/amdgpu: adjust default display clock

2017-06-29T11:00:30+00:00

commit 52b482b0f4fd6d5267faf29fe91398e203f3c230 upstream.

Increase the default display clock on newer asics to
accomodate some high res modes with really high refresh
rates.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=93826
Acked-by: Chunming Zhou 
Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating

2017-06-29T11:00:30+00:00

commit 05b4017b37f1fce4b7185f138126dd8decdb381f upstream.

We were using the wrong structure which lead to an overflow
on some boards.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=101387
Acked-by: Chunming Zhou 
Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: add a quirk for Toshiba Satellite L20-183

2017-06-29T11:00:30+00:00

commit acfd6ee4fa7ebeee75511825fe02be3f7ac1d668 upstream.

Fixes resume from suspend.

bug: https://bugzilla.kernel.org/show_bug.cgi?id=196121
Reported-by: Przemek 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: add a PX quirk for another K53TK variant

2017-06-29T11:00:30+00:00

commit 4eb59793cca00b0e629b6d55b5abb5acb82c5868 upstream.

Disable PX on these systems.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=101491
Signed-off-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

2017-06-24T05:11:14+00:00

commit ca39b449f6d03e8235969f12f5dd25b8eb4304d6 upstream.

If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache.  If we then reused it before it expired from the cache,
the kernel would OOPS.

Signed-off-by: Eric Anholt 
Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")
Reviewed-by: Boris Brezillon 
Link: http://patchwork.freedesktop.org/patch/msgid/20170301185602.6873-2-eric@anholt.net
Signed-off-by: Greg Kroah-Hartman

drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake

2017-06-24T05:11:14+00:00

commit 014580ffab654bb83256783a2b185cf6c06dffaa upstream.

mtk_hdmi_setup_vendor_specific_infoframe will return before handle
mtk_hdmi_hw_send_info_frame.Because hdmi_vendor_infoframe_pack
returns the number of bytes packed into the binary buffer or
a negative error code on failure.
So correct it.

Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Signed-off-by: Nickey Yang 
Signed-off-by: CK Hu 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix GVT-g PVINFO version compatibility check

2017-06-24T05:11:13+00:00

commit c380f681245d7ae57f17d9ebbbe8f8f1557ee1fb upstream.

Current it's strictly checked if PVINFO version matches 1.0
for GVT-g i915 guest which doesn't help for compatibility at
all and forces GVT-g host can't extend PVINFO easily with version
bump for real compatibility check.

This fixes that to check minimal required PVINFO version instead.

v2:
- drop unneeded version macro
- use only major version for sanity check

v3:
- fix up PVInfo value with kernel type
- one indent fix

Reviewed-by: Joonas Lahtinen 
Cc: Chuanxiao Dong 
Cc: Joonas Lahtinen 
Signed-off-by: Zhenyu Wang 
Signed-off-by: Joonas Lahtinen 
Link: http://patchwork.freedesktop.org/patch/msgid/20170609074805.5101-1-zhenyuw@linux.intel.com
(cherry picked from commit 0c8792d00d38de85b6ceb1dd67d3ee009d7c8e42)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix overflow of watermark calcs at > 4k resolutions.

2017-06-24T05:11:13+00:00

commit bea10413934dcf98cb9b2dfcdc56e1d28f192897 upstream.

Commit d63c277dc672e0
("drm/amdgpu: Make display watermark calculations more accurate")
made watermark calculations more accurate, but not for > 4k
resolutions on 32-Bit architectures, as it introduced an integer
overflow for those setups and resolutions.

Fix this by proper u64 casting and division.

Signed-off-by: Mario Kleiner 
Reported-by: Ben Hutchings 
Fixes: d63c277dc672 ("drm/amdgpu: Make display watermark calculations more accurate")
Cc: Ben Hutchings 
Cc: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

2017-06-17T04:41:58+00:00

commit 4e3aed844547f63614363a386de126e6304e55fb upstream.

On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.

Changes since v1:
- Do not take the connection_mutex, this is already done below.

Reported-by: Maarten Lankhorst 
Inspired-by: Mahesh Kumar 
Signed-off-by: Maarten Lankhorst 
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc: Mahesh Kumar 
Cc: Matt Roper 
Link: http://patchwork.freedesktop.org/patch/msgid/20170531154236.27180-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Mahesh Kumar 
Reviewed-by: Matt Roper 
Signed-off-by: Greg Kroah-Hartman 

(cherry picked from commit 367d73d2806085bb507ab44c1f532640917fd5ca)
Signed-off-by: Jani Nikula

drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail

2017-06-17T04:41:58+00:00

commit 8f4d38099b3098eae75f7755e1801931f8141350 upstream.

The scanline counter is bonkers on VLV/CHV DSI. The scanline counter
increment is not lined up with the start of vblank like it is on
every other platform and output type. This causes problems for
both the vblank timestamping and atomic update vblank evasion.

On my FFRD8 machine at least, the scanline counter increment
happens about 1/3 of a scanline ahead of the start of vblank (which
is where all register latching happens still). That means we can't
trust the scanline counter to tell us whether we're in vblank or not
while we're on that particular line. In order to keep vblank
timestamping in working condition when called from the vblank irq,
we'll leave scanline_offset at one, which means that the entire
line containing the start of vblank is considered to be inside
the vblank.

For the vblank evasion we'll need to consider that entire line
to be bad, since we can't tell whether the registers already
got latched or not. And we can't actually use the start of vblank
interrupt to get us past that line as the interrupt would fire
too soon, and then we'd up waiting for the next start of vblank
instead. One way around that would using the frame start
interrupt instead since that wouldn't fire until the next
scanline, but that would require some bigger changes in the
interrupt code. So for simplicity we'll just poll until we get
past the bad line.

v2: Adjust the comments a bit

Cc: Jonas Aaberg 
Tested-by: Jonas Aaberg 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20161215174734.28779-1-ville.syrjala@linux.intel.com
Tested-by: Mika Kahola 
Reviewed-by: Mika Kahola 
(cherry picked from commit ec1b4ee2834e66884e5b0d3d465f347ff212e372)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman