linux-stable.git/drivers/gpu, branch v3.18.26

drm/radeon: don't try to recreate sysfs entries on resume

2015-11-15T17:51:49+00:00

[ Upstream commit 49abb26651167c892393cd9f2ad23df429645ed9 ]

Fixes a harmless error message caused by:
51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/i915: Restore lost DPLL register write on gen2-4

2015-11-15T17:51:49+00:00

[ Upstream commit 8e7a65aa70bcc1235a44e40ae0da5056525fe081 ]

We accidentally lost the initial DPLL register write in
1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M

The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.

Reported-and-tested-by: Nick Bowler 
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: stable@vger.kernel.org
Cc: Nick Bowler 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/nouveau/gem: return only valid domain when there's only one

2015-11-15T17:51:49+00:00

[ Upstream commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 ]

On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.

This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin

drm/radeon: add pm sysfs files late

2015-11-13T18:19:32+00:00

[ Upstream commit 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 ]

They were added relatively early in the driver init process
which meant that in some cases the driver was not finished
initializing before external tools tried to use them which
could result in a crash depending on the timing.

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/nouveau/fbcon: take runpm reference when userspace has an open fd

2015-11-13T18:19:22+00:00

[ Upstream commit f231976c2e8964ceaa9250e57d27c35ff03825c2 ]

We need to do this in order to prevent accesses to the device while it's
powered down.  Userspace may have an mmap of the fb, and there's no good
way (that I know of) to prevent it from touching the device otherwise.

This fixes some nasty races between runpm and plymouth on some systems,
which result in the GPU getting very upset and hanging the boot.

Signed-off-by: Ben Skeggs 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/qxl: validate monitors config modes

2015-10-28T02:14:32+00:00

[ Upstream commit bd3e1c7c6de9f5f70d97cdb6c817151c0477c5e3 ]

Due to some recent changes in
drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
were not being pruned properly. In current kernels,
drm_mode_validate_basic() is called to sanity-check each mode in the
list. If the sanity-check passes, the mode's status gets set to to
MODE_OK. In older kernels this check was not done, so old custom modes
would still have a status of MODE_UNVERIFIED at this point, and would
therefore be pruned later in the function.

As a result of this new behavior, the list of modes for a device always
includes every custom mode ever configured for the device, with the
largest one listed first. Since desktop environments usually choose the
first preferred mode when a hotplug event is emitted, this had the
result of making it very difficult for the user to reduce the size of
the display.

The qxl driver did implement the mode_valid connector function, but it
was empty. In order to restore the old behavior where old custom modes
are pruned, we implement a proper mode_valid function for the qxl
driver. This function now checks each mode against the last configured
custom mode and the list of standard modes. If the mode doesn't match
any of these, its status is set to MODE_BAD so that it will be pruned as
expected.

Signed-off-by: Jonathon Jongsma 
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin

drm/amdgpu: Don't link train DisplayPort on HPD until we get the dpcd

2015-10-28T02:14:31+00:00

[ Upstream commit a887adadb7b9ef9eb4ee48e4ad575aefcfd1db14 ]

This is a port of:
DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd
to amdgpu.

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm/amdgpu: Restore LCD backlight level on resume

2015-10-28T02:13:44+00:00

[ Upstream commit 74b3112e95073b351e3b0b9799795bc76f8415fa ]

Instead of only enabling the backlight (which seems to set it to max
brightness), just re-set the current backlight level, which also takes
care of enabling the backlight if necessary.

Port of radeon commit:
drm/radeon: Restore LCD backlight level on resume (>= R5xx)

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

drm: Reject DRI1 hw lock ioctl functions for kms drivers

2015-10-28T02:13:43+00:00

[ Upstream commit da168d81b44898404d281d5dbe70154ab5f117c1 ]

I've done some extensive history digging across libdrm, mesa and
xf86-video-{intel,nouveau,ati}. The only potential user of this with
kms drivers I could find was ttmtest, which once used drmGetLock
still. But that mistake was quickly fixed up. Even the intel xvmc
library (which otherwise was really good with using dri1 stuff in kms
mode) managed to never take the hw lock for dri2 (and hence kms).

Hence it should be save to unconditionally disallow this.

Cc: Peter Antoine 
Reviewed-by: Peter Antoine 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin

drm/i915/bios: handle MIPI Sequence Block v3+ gracefully

2015-10-28T02:13:43+00:00

[ Upstream commit cd67d226ebd909d239d2c6e5a6abd6e2a338d1cd ]

The VBT MIPI Sequence Block version 3 has forward incompatible changes:

First, the block size in the header has been specified reserved, and the
actual size is a separate 32-bit value within the block. The current
find_section() function to will only look at the size in the block
header, and, depending on what's in that now reserved size field,
continue looking for other sections in the wrong place.

Fix this by taking the new block size field into account. This will
ensure that the lookups for other sections will work properly, as long
as the new 32-bit size does not go beyond the opregion VBT mailbox size.

Second, the contents of the block have been completely
changed. Gracefully refuse parsing the yet unknown data version.

Cc: Deepak M 
Cc: stable@vger.kernel.org
Reviewed-by: Deepak M 
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin