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

drm/radeon: use rv515_ring_start on r5xx

2015-01-30T01:40:43+00:00

commit d8a74e186949e1a2c2f1309212478b0659bf9225 upstream.

This was accidently lost in 76a0df859def.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: add si dpm quirk list

2015-01-30T01:40:43+00:00

commit 5615f890bc6babdc2998dec62f3552326d06eb7b upstream.

This adds a quirks list to fix stability problems with
certain SI boards.

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

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: add a dpm quirk list

2015-01-30T01:40:43+00:00

commit 4369a69ec6ab86821352bd753c68af5880f87956 upstream.

Disable dpm on certain problematic boards rather than
disabling dpm for the entire chip family since most
boards work fine.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534
https://bugzilla.kernel.org/show_bug.cgi?id=83731

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES

2015-01-30T01:40:43+00:00

commit 226e5ae9e5f9108beb0bde4ac69f68fe6210fed9 upstream.

If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared
if the mutex debugging is enabled which introduces a race in our
mutex_is_locked_by() - i.e. we may inspect the old owner value before it
is acquired by the new task.

This is the root cause of this error:

# diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
# index 5cf6731..3ef3736 100644
# --- a/kernel/locking/mutex-debug.c
# +++ b/kernel/locking/mutex-debug.c
# @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex *lock)
# 			DEBUG_LOCKS_WARN_ON(lock->owner != current);
#
# 		DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
# -		mutex_clear_owner(lock);
# 	}
#
# 	/*
# 	 * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
# 	 * mutexes so that we can do it here after we've verified state.
# 	 */
# +	mutex_clear_owner(lock);
# 	atomic_set(&lock->count, 1);
#  }

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955
Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Ban Haswell from using RCS flips

2015-01-30T01:40:43+00:00

commit 48bf5b2d00bfeb681f6500c626189c7cd2c964d2 upstream.

Like Ivybridge, we have reports that we get random hangs when flipping
with multiple pipes. Extend

commit 2a92d5bca1999b69c78f3c3e97b5484985b094b9
Author: Chris Wilson 
Date:   Tue Jul 8 10:40:29 2014 +0100

    drm/i915: Disable RCS flips on Ivybridge

to also apply to Haswell.

Reported-and-tested-by: Scott Tsai 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759
Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Kill check_power_well() calls

2015-01-27T16:29:46+00:00

commit 7f1241ed1a06b4846ad7a2a57eb088b757e58e16 upstream.

pps_{lock,unlock}() call intel_display_power_{get,put}() outside
pps_mutes to avoid deadlocks with the power_domain mutex. In theory
during aux transfers we should usually have the relevant power domain
references already held by some higher level code, so this should not
result in much overhead (exception being userspace i2c-dev access).
However thanks to the check_power_well() calls in
intel_display_power_{get/put}() we end up doing a few Punit reads for
each aux transfer. Obviously doing this for each byte transferred via
i2c-over-aux is not a good idea.

I can't think of a good way to keep check_power_well() while eliminating
the overhead, so let's just remove check_power_well() entirely.

Fixes a driver init time regression introduced by:
 commit 773538e86081d146e0020435d614f4b96996c1f9
 Author: Ville Syrjälä 
 Date:   Thu Sep 4 14:54:56 2014 +0300

    drm/i915: Reset power sequencer pipe tracking when disp2d is off

Credit goes to Jani for figuring this out.

v2: Add the regression note in the commit message.

Cc: Egbert Eich 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201
Tested-by: Wendy Wang 
Signed-off-by: Ville Syrjälä 
[Jani: s/intel_runtime_pm.c/intel_pm.c/g and wiggle for 3.18]
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

Revert "drm/i915: Preserve VGACNTR bits from the BIOS"

2015-01-27T16:29:38+00:00

commit 01f5a6261cea395f72877aeb7c2fe2d42e1b1e00 upstream.

The VGA_2X_MODE bit apparently affects the display even when the VGA
plane is disabled. The bit will set by the BIOS when the panel width
is at least 1280 pixels. So by preserving the bit from the BIOS we
end up with corrupted display on machines with such high res panels.
I only have 1024x768 panels on my gen2 machines so never ran into
this problem.

The original reason for preserving the VGACNTR register was to make
my 830 survive S3 with acpi_sleep=s3_bios option. However after
further 830 fixes that option is no longer needed to make S3 work
and preserving VGACNTR doesn't seem to be necessary without it,
so we can just revert the entire patch.

This reverts
commit 69769f9a422bfc62e17399da3590c5e31ac37f24
Author: Ville Syrjälä 
Date:   Fri Aug 15 01:22:08 2014 +0300

    drm/i915: Preserve VGACNTR bits from the BIOS

Cc: Bruno Prémont 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171
Signed-off-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/irq: BUG_ON() -> WARN_ON()

2015-01-27T16:29:35+00:00

commit 7f907bf284ba7bb8d271f094b226699d3fef2142 upstream.

Let's make things a bit easier to debug when things go bad (potentially
under console_lock).

Signed-off-by: Rob Clark 
Reviewed-by: Michel Dänzer 
Signed-off-by: Dave Airlie 
Cc: Anand Moon 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Don't call intel_prepare_page_flip() multiple times on gen2-4

2015-01-27T16:29:35+00:00

commit 7d47559ee84b3ac206aa9e675606fafcd7c0b500 upstream.

The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That
means if we first call intel_prepare_page_flip() but don't call
intel_finish_page_flip(), the next stall check will erroneosly think
the page flip was somehow stuck.

With enough debug spew emitted from the interrupt handler my 830 hangs
when this happens. My theory is that the previous vblank interrupt gets
sufficiently delayed that the handler will see the pending bit set in
IIR, but ISR still has the bit set as well (ie. the flip was processed
by CS but didn't complete yet). In this case the handler will proceed
to call intel_check_page_flip() immediately after
intel_prepare_page_flip(). It then tries to print a backtrace for the
stuck flip WARN, which apparetly results in way too much debug spew
delaying interrupt processing further. That then seems to cause an
endless loop in the interrupt handler, and the machine is dead until
the watchdog kicks in and reboots. At least limiting the number of
iterations of the loop in the interrupt handler also prevented the
hang.

So it seems better to not call intel_prepare_page_flip() without
immediately calling intel_finish_page_flip(). The IIR/ISR trickery
avoids races here so this is a perfectly safe thing to do.

v2: Fix typo in commit message (checkpatch)

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888
Reviewed-by: Chris Wilson 
Signed-off-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Disable PSMI sleep messages on all rings around context switches

2015-01-27T16:29:35+00:00

commit 2c550183476dfa25641309ae9a28d30feed14379 upstream.

There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang.  Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.

Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.

v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Tested-by: Peter Frühberger 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman