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

drm/radeon: add pm sysfs files late

2015-10-27T00:51:57+00:00

commit 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: attach tile property to mst connector

2015-10-27T00:51:57+00:00

commit bc8c131ccdd62d4ed4f33c6b50f92907e7c32dee upstream.

This allows tiled monitors to work with radeon once mst is enabled.

Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/dp/mst: make mst i2c transfer code more robust.

2015-10-27T00:51:57+00:00

commit ae491542cbbbcca0ec8938c37d4079a985e58440 upstream.

This zeroes the msg so no random stack data ends up getting
sent, it also limits the function to not accepting > 4
i2c msgs.

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

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

2015-10-27T00:51:56+00:00

commit f231976c2e8964ceaa9250e57d27c35ff03825c2 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

drm: Fix locking for sysfs dpms file

2015-10-27T00:51:53+00:00

commit 621bd0f6982badd6483acb191eb7b6226a578328 upstream.

With atomic drivers we need to make sure that (at least in general)
property reads hold the right locks. But the legacy dpms property is
special and can be read locklessly. Since userspace loves to just
randomly look at that all the time (like with "status") do that.

To make it clear that we play tricks use the READ_ONCE compiler
barrier (and also for paranoia).

Note that there's not really anything bad going on since even with the
new atomic paths we eventually end up not chasing any pointers (and
hence possibly freed memory and other fun stuff). The locking WARNING
has been added in

commit 88a48e297b3a3bac6022c03babfb038f1a886cea
Author: Rob Clark 
Date:   Thu Dec 18 16:01:50 2014 -0500

    drm: add atomic properties

but since drivers are converting not everyone will have seen this from
the start.

Jens reported this and submitted a patch to just grab the
mode_config.connection_mutex, but we can do a bit better.

v2: Remove unused variables I failed to git add for real.

Reference: http://mid.gmane.org/20150928194822.GA3930@kernel.dk
Reported-by: Jens Axboe 
Tested-by: Jens Axboe 
Cc: Rob Clark 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/dp/mst: drop cancel work sync in the mstb destroy path (v2)

2015-10-22T21:43:19+00:00

commit 274d83524895fe41ca8debae4eec60ede7252bb5 upstream.

Since 9eb1e57f564d4e6e10991402726cc83fe0b9172f
drm/dp/mst: make sure mst_primary mstb is valid in work function

we validate the mstb structs in the work function, and doing
that takes a reference. So we should never get here with the
work function running using the mstb device, only if the work
function hasn't run yet or is running for another mstb.

So we don't need to sync the work here, this was causing
lockdep spew as below.

[  +0.000160] =============================================
[  +0.000001] [ INFO: possible recursive locking detected ]
[  +0.000002] 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 Tainted: G        W      ------------
[  +0.000001] ---------------------------------------------
[  +0.000001] kworker/4:2/1262 is trying to acquire lock:
[  +0.000001]  ((&mgr->work)){+.+.+.}, at: [] flush_work+0x5/0x2e0
[  +0.000007]
but task is already holding lock:
[  +0.000001]  ((&mgr->work)){+.+.+.}, at: [] process_one_work+0x1b4/0x710
[  +0.000004]
other info that might help us debug this:
[  +0.000001]  Possible unsafe locking scenario:

[  +0.000002]        CPU0
[  +0.000000]        ----
[  +0.000001]   lock((&mgr->work));
[  +0.000002]   lock((&mgr->work));
[  +0.000001]
 *** DEADLOCK ***

[  +0.000001]  May be due to missing lock nesting notation

[  +0.000002] 2 locks held by kworker/4:2/1262:
[  +0.000001]  #0:  (events_long){.+.+.+}, at: [] process_one_work+0x1b4/0x710
[  +0.000004]  #1:  ((&mgr->work)){+.+.+.}, at: [] process_one_work+0x1b4/0x710
[  +0.000003]
stack backtrace:
[  +0.000003] CPU: 4 PID: 1262 Comm: kworker/4:2 Tainted: G        W      ------------   3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1
[  +0.000001] Hardware name: LENOVO 20EGS0R600/20EGS0R600, BIOS GNET71WW (2.19 ) 02/05/2015
[  +0.000008] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
[  +0.000001]  ffffffff82c26c90 00000000a527b914 ffff88046399bae8 ffffffff816fe04d
[  +0.000004]  ffff88046399bb58 ffffffff8110f47f ffff880461438000 0001009b840fc003
[  +0.000002]  ffff880461438a98 0000000000000000 0000000804dc26e1 ffffffff824a2c00
[  +0.000003] Call Trace:
[  +0.000004]  [] dump_stack+0x19/0x1b
[  +0.000004]  [] __lock_acquire+0x115f/0x1250
[  +0.000002]  [] lock_acquire+0x99/0x1e0
[  +0.000002]  [] ? flush_work+0x5/0x2e0
[  +0.000002]  [] flush_work+0x4e/0x2e0
[  +0.000002]  [] ? flush_work+0x5/0x2e0
[  +0.000004]  [] ? native_sched_clock+0x35/0x80
[  +0.000002]  [] ? sched_clock+0x9/0x10
[  +0.000002]  [] ? local_clock+0x25/0x30
[  +0.000002]  [] ? mark_held_locks+0xb9/0x140
[  +0.000003]  [] ? __cancel_work_timer+0x95/0x160
[  +0.000002]  [] __cancel_work_timer+0xa8/0x160
[  +0.000002]  [] cancel_work_sync+0x10/0x20
[  +0.000007]  [] drm_dp_destroy_mst_branch_device+0x27/0x120 [drm_kms_helper]
[  +0.000006]  [] drm_dp_mst_link_probe_work+0x78/0xa0 [drm_kms_helper]
[  +0.000002]  [] process_one_work+0x220/0x710
[  +0.000002]  [] ? process_one_work+0x1b4/0x710
[  +0.000005]  [] worker_thread+0x11b/0x3a0
[  +0.000003]  [] ? process_one_work+0x710/0x710
[  +0.000002]  [] kthread+0xed/0x100
[  +0.000003]  [] ? insert_kthread_work+0x80/0x80
[  +0.000003]  [] ret_from_fork+0x58/0x90

v2: add flush_work.

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

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

2015-10-22T21:43:19+00:00

commit 4281f46ef839050d2ef60348f661eb463c21cc2e upstream.

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.

Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop,
the radeon_atom_encoder_dpms_avivo part is only compile tested.

Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm: Reject DRI1 hw lock ioctl functions for kms drivers

2015-10-22T21:43:19+00:00

commit da168d81b44898404d281d5dbe70154ab5f117c1 upstream.

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: Greg Kroah-Hartman

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

2015-10-22T21:43:19+00:00

commit cd67d226ebd909d239d2c6e5a6abd6e2a338d1cd upstream.

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 
Reviewed-by: Deepak M 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/qxl: recreate the primary surface when the bo is not primary

2015-10-22T21:43:18+00:00

commit 8d0d94015e96b8853c4f7f06eac3f269e1b3d866 upstream.

When disabling/enabling a crtc the primary area must be updated
independently of which crtc has been disabled/enabled.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735

Signed-off-by: Fabiano Fidêncio 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman