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

drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"

2016-08-20T16:11:00+00:00

commit 196f954e250943df414efd3d632254c29be38e59 upstream.

This reverts commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")

This commit introduced a regression into stable kernels,
as it reduces output color depth to 6 bpc for any video
sink connected to a Displayport connector if that sink
doesn't report a specific color depth via EDID, or if
our EDID parser doesn't actually recognize the proper
bpc from EDID.

Affected are active DisplayPort->VGA converters and
active DisplayPort->DVI converters. Both should be
able to handle 8 bpc, but are degraded to 6 bpc with
this patch.

The reverted commit was meant to fix
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331

A followup patch implements a fix for that specific bug,
which is caused by a faulty EDID of the affected DP panel
by adding a new EDID quirk for that panel.

DP 18 bpp fallback handling and other improvements to
DP sink bpc detection will be handled for future
kernels in a separate series of patches.

Please backport to stable.

Signed-off-by: Mario Kleiner 
Acked-by: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB

2016-08-20T16:11:00+00:00

commit a7b4667a00025ac28300737c868bd4818b6d8c4d upstream.

SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
in an infinite batch buffer loop. The GPU apparently hogs something
critical and CPUs start to lose interrupts and whatnot. We can keep
the system limping along by unmasking some interrupts in
GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for
that task, so let's never mask it.

v2: s/gen6_rps_pm_mask/gen6_sanitize_rps_pm_mask/ (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93122
Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: http://patchwork.freedesktop.org/patch/msgid/1464014568-4529-1-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 12c100bfa5d9103b6c4d43636fee09c31e75605a)
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/edid: Add 6 bpc quirk for display AEO model 0.

2016-08-20T16:11:00+00:00

commit e10aec652f31ec61d6a0b4d00d8ef8d2b66fa0fd upstream.

Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
reports that the "AEO model 0" display is driven with 8 bpc
without dithering by default, which looks bad because that
panel is apparently a 6 bpc DP panel with faulty EDID.

A fix for this was made by commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").

That commit triggers new regressions in precision for DP->DVI and
DP->VGA displays. A patch is out to revert that commit, but it will
revert video output for the AEO model 0 panel to 8 bpc without
dithering.

The EDID 1.3 of that panel, as decoded from the xrandr output
attached to that bugzilla bug report, is somewhat faulty, and beyond
other problems also sets the "DFP 1.x compliant TMDS" bit, which
according to DFP spec means to drive the panel with 8 bpc and
no dithering in absence of other colorimetry information.

Try to make the original bug reporter happy despite the
faulty EDID by adding a quirk to mark that panel as 6 bpc,
so 6 bpc output with dithering creates a nice picture.

Tested by injecting the edid from the fdo bug into a DP connector
via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
is selected.

This patch should be backported to stable.

Signed-off-by: Mario Kleiner 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm: aux ->transfer() can return 0, deal with it

2016-08-20T16:11:00+00:00

commit a1f5524a66ff6284d1380cdd7723de82698ff9d3 upstream.

Restore the correct behaviour (as in check msg.reply) when aux
->transfer() returns 0. It got removed in
commit 82922da39190 ("drm/dp_helper: Retry aux transactions on all errors")

Now I can actually dump the "entire" DPCD on a Dell UP2314Q with
ddrescue. It has some offsets in the DPCD that can't be read
for some resaon, all you get is defers. Previously ddrescue would
just give up at the first unredable offset on account of
read() returning 0 means EOF. Here's the ddrescue log
for the interested:
0x00000000  0x00001400  +
0x00001400  0x00000030  -
0x00001430  0x000001D0  +
0x00001600  0x00000030  -
0x00001630  0x0001F9D0  +
0x00021000  0x00000001  -
0x00021001  0x000DEFFF  +

Cc: Lyude 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915/gen9: Add WaInPlaceDecompressionHang

2016-08-20T16:11:00+00:00

commit f15f6ca1e706e11fd07611bd4c7f903625349b33 upstream.

Add this workaround to prevent hang when in place compression
is used.

References: HSD#2135774
Signed-off-by: Mika Kuoppala 
Reviewed-by: Arun Siluvery 
Signed-off-by: Joonas Lahtinen 
(cherry picked from commit 4ba9c1f7c7b8ca8c1d77f65d408e589dc87b9a2d)
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/rockchip: allocate correct crtc state structure on reset

2016-08-20T16:11:00+00:00

commit dc0b408f5a87cce3ea3f81a6800244fb7d395435 upstream.

Because we are using a custom crtc_state structure, we must override the
reset helper to allocate the correct amount of memory.

Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
Reviewed-by: Sean Paul 
Signed-off-by: Greg Kroah-Hartman

drm/amd/powerplay: fix the incorrect return value

2016-08-20T16:11:00+00:00

commit bec5f70dad45f7ad63f97aa0988821532ebeade7 upstream.

The return value 0 (false) means fail to find GPIO in
atomctrl_get_pp_assign_pin. "-1" returns true as bool actually.

Signed-off-by: Huang Rui 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Update CDCLK_FREQ register on BDW after changing cdclk frequency

2016-08-20T16:11:00+00:00

commit 7f1052a8fa38df635ab0dc0e6025b64ab9834824 upstream.

Update CDCLK_FREQ on BDW after changing the cdclk frequency. Not sure
if this is a late addition to the spec, or if I simply overlooked this
step when writing the original code.

This is what Bspec has to say about CDCLK_FREQ:
"Program this field to the CD clock frequency minus one. This is used to
 generate a divided down clock for miscellaneous timers in display."

And the "Broadwell Sequences for Changing CD Clock Frequency" section
clarifies this further:
"For CD clock 337.5 MHz, program 337 decimal.
 For CD clock 450 MHz, program 449 decimal.
 For CD clock 540 MHz, program 539 decimal.
 For CD clock 675 MHz, program 674 decimal."

Cc: Mika Kahola 
Fixes: b432e5cfd5e9 ("drm/i915: BDW clock change support")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1461689194-6079-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola 
Signed-off-by: Greg Kroah-Hartman

drm: Restore double clflush on the last partial cacheline

2016-08-20T16:11:00+00:00

commit 396f5d62d1a5fd99421855a08ffdef8edb43c76e upstream.

This effectively reverts

commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson 
Date:   Wed Jun 10 15:58:01 2015 +0100

    drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()

as we have observed issues with serialisation of the clflush operations
on Baytrail+ Atoms with partial updates. Applying the double flush on the
last cacheline forces that clflush to be ordered with respect to the
previous clflush, and the mfence then protects against prefetches crossing
the clflush boundary.

The same issue can be demonstrated in userspace with igt/gem_exec_flush.

Fixes: afcd950cafea6 (drm: Avoid the double clflush on the last cache...)
Testcase: igt/gem_concurrent_blit
Testcase: igt/gem_partial_pread_pwrite
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92845
Signed-off-by: Chris Wilson 
Cc: dri-devel@lists.freedesktop.org
Cc: Akash Goel 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Reviewed-by: Mika Kuoppala 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1467880930-23082-6-git-send-email-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/fbcon: fix font width not divisible by 8

2016-08-20T16:10:59+00:00

commit 28668f43b8e421634e1623f72a879812288dd06b upstream.

The patch f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the
display when using fonts with width that is not divisiable by 8.

The monochrome bitmap for each character is stored in memory by lines from top
to bottom. Each line is padded to a full byte.

For example, for 22x11 font, each line is padded to 16 bits, so each
character is consuming 44 bytes total, that is 11 32-bit words. The patch
f045f459d925 changed the logic to "dsize = ALIGN(image->width *
image->height, 32) >> 5", that is just 8 words - this is incorrect and it
causes display corruption.

This patch adds the necesary padding of lines to 8 bytes.

This patch should be backported to stable kernels where f045f459d925 was
backported.

Signed-off-by: Mikulas Patocka 
Fixes: f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses")
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman