linux.git/drivers/gpu, branch v3.12.61

drm/fb_helper: Fix references to dev->mode_config.num_connector

2016-06-15T07:32:15+00:00

commit 255f0e7c418ad95a4baeda017ae6182ba9b3c423 upstream.

During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:

- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
  of dev->mode_config.num_connectors, and end up going out of bounds
  since dev->mode_config.num_connectors is now larger then the array we
  allocated.

fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.

Note: This is just polish for 4.7, Dave Airlie's drm_connector
refcounting fixed these bugs for real. But it's good enough duct-tape
for stable kernel backporting, since backporting the refcounting
changes is way too invasive.

Signed-off-by: Lyude 
[danvet: Clarify why we need this. Also remove the now unused "dev"
local variable to appease gcc.]
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-3-git-send-email-cpaul@redhat.com
Signed-off-by: Jiri Slaby

drm/gma500: Fix possible out of bounds read

2016-06-15T07:32:15+00:00

commit 7ccca1d5bf69fdd1d3c5fcf84faf1659a6e0ad11 upstream.

Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).

Signed-off-by: Itai Handler 
Signed-off-by: Patrik Jakobsson 
Signed-off-by: Jiri Slaby

drm/i915: Bail out of pipe config compute loop on LPT

2016-05-18T06:40:06+00:00

commit 2700818ac9f935d8590715eecd7e8cadbca552b6 upstream.

LPT is pch, so might run into the fdi bandwidth constraint (especially
since it has only 2 lanes). But right now we just force pipe_bpp back
to 24, resulting in a nice loop (which we bail out with a loud
WARN_ON). Fix this.

Cc: Chris Wilson 
Cc: Maarten Lankhorst 
References: https://bugs.freedesktop.org/show_bug.cgi?id=93477
Signed-off-by: Daniel Vetter 
Tested-by: Chris Wilson 
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch
(cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f)
Signed-off-by: Jani Nikula 
Signed-off-by: Jiri Slaby

drm/radeon: fix PLL sharing on DCE6.1 (v2)

2016-05-18T06:40:06+00:00

commit e3c00d87845ab375f90fa6e10a5e72a3a5778cd3 upstream.

On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not
be taken into consideration when looking for an already enabled PLL
to be shared with other outputs.

This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland
based laptop, where the internal display is connected to UNIPHYA through
a TRAVIS DP->LVDS bridge.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78987

v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
    extra parameter.

Signed-off-by: Lucas Stach 
Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/qxl: fix cursor position with non-zero hotspot

2016-05-02T17:54:56+00:00

commit d59a1f71ff1aeda4b4630df92d3ad4e3b1dfc885 upstream.

The SPICE protocol considers the position of a cursor to be the location
of its active pixel on the display, so the cursor is drawn with its
top-left corner at "(x - hot_spot_x, y - hot_spot_y)" but the DRM cursor
position gives the location where the top-left corner should be drawn,
with the hotspot being a hint for drivers that need it.

This fixes the location of the window resize cursors when using Fluxbox
with the QXL DRM driver and both the QXL and modesetting X drivers.

Signed-off-by: John Keeping 
Reviewed-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1447845445-2116-1-git-send-email-john@metanate.com
Signed-off-by: Jani Nikula 
Signed-off-by: Jiri Slaby

drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)

2016-04-20T06:46:50+00:00

[Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with
 an additional NULL pointer guard that is required for kernels 3.17 and older.

 To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon:
 use common fence implementation for fences, v4" requires this additional
 NULL pointer guard.]

An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.

Based on the analogous fix for amdgpu.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Christian König  (v1 + fix)
Tested-by: Lutz Euler 
Signed-off-by: Jiri Slaby

drm/radeon: add a dpm quirk for all R7 370 parts

2016-04-20T06:40:09+00:00

commit 0e5585dc870af947fab2af96a88c2d8b4270247c upstream.

Higher mclk values are not stable due to a bug somewhere.
Limit them for now.

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/radeon: add a dpm quirk for sapphire Dual-X R7 370 2G D5

2016-04-20T06:40:09+00:00

commit f971f2263deaa4a441e377b385c11aee0f3b3f9a upstream.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=94692

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.

2016-04-11T14:44:21+00:00

commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream.

As observed on Apple iMac10,1, DCE-3.2, RV-730,
link rate of 2.7 Ghz is not selected, because
the args.v1.ucConfig flag setting for 2.7 Ghz
gets overwritten by a following assignment of
the transmitter to use.

Move link rate setup a few lines down to fix this.
In practice this didn't have any positive or
negative effect on display setup on the tested
iMac10,1 so i don't know if backporting to stable
makes sense or not.

Signed-off-by: Mario Kleiner 
Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"

2016-03-14T12:34:17+00:00

This reverts commit 40df18b49e7fe4ec9ab93f68c33661ee291149bd, commit
f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.

It causes oopses:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [] radeon_fence_ref+0xd/0x50 [radeon]

Signed-off-by: Jiri Slaby 
Cc: Nicolai Hähnle 
Cc: Christian König