linux-toradex.git/drivers/gpu/drm, branch v3.10.29

drm/nouveau/bios: fix offset calculation for BMPv1 bioses

2014-02-06T19:08:12+00:00

commit 5d2f4767c4eacab351b8450b0de4d3261fe1a957 upstream.

The only BIOS on record that needs the 14 offset has a bios major
version 2 but BMP version 1.01. Another bunch of BIOSes that need the 18
offset have BMP version 2.01 or 5.01 or higher. So instead of looking at the
bios major version, look at the BMP version. BIOSes with BMP version 0
do not contain a detectable script, so always return 0 for them.

See https://bugs.freedesktop.org/show_bug.cgi?id=68835

Reported-by: Mauro Molinari 
Signed-off-by: Ilia Mirkin 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()

2014-01-25T16:27:12+00:00

commit 7ad228b11ec26a820291c9f5a1168d6176580dc1 upstream.

When the pipe A force quirk is applied the code will attempt to grab
a crtc mutex during intel_modeset_setup_hw_state(). If we're already
holding all crtc mutexes this will obviously deadlock every time.

So instead of using drm_modeset_lock_all() just grab the
mode_config.mutex. This is enough to avoid the unlocked mutex warnings
from certain lower level functions.

The regression was introduced in:

 commit 027476642811f8559cbe00ef6cc54db230e48a20
 Author: Ville Syrjälä 
 Date:   Mon Dec 2 11:08:06 2013 +0200

    drm/i915: Take modeset locks around intel_modeset_setup_hw_state()

Signed-off-by: Ville Syrjälä 
[danvet: Add cc: stable since the offending commit has that, too.]
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix DDI PLLs HW state readout code

2014-01-25T16:27:12+00:00

commit 0882dae983707455e97479e5e904e37673517ebc upstream.

Properly zero the refcounts and crtc->ddi_pll_set so the previous HW
state doesn't affect the result of reading the current HW state.

This fixes WARNs about WRPLL refcount if we have an HDMI monitor on
HSW and then suspend/resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64379
Tested-by: Qingshuai Tian 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/bios: make jump conditional

2014-01-15T23:28:51+00:00

commit 6d60792ec059d9f2139828f9f017679abb81aa73 upstream.

This fixes a hang in VBIOS scripts of the form "condition; jump".
The jump used to always be executed, while now it will only be
executed if the condition is true.

See https://bugs.freedesktop.org/show_bug.cgi?id=72943

Reported-by: Darcy Brás da Silva 
Signed-off-by: Ilia Mirkin 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix UVD 256MB check

2014-01-09T20:24:22+00:00

commit bae651dbd7ade3c5d6518f89599ae680a2fe2b85 upstream.

Otherwise the kernel might reject our decoding requests.

Signed-off-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Use the correct GMCH_CTRL register for Sandybridge+

2014-01-09T20:24:22+00:00

commit a885b3ccc74d8e38074e1c43a47c354c5ea0b01e upstream.

The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.

Note that the register is still marked as locked RO on Sandybridge, so
vgaarb is still dysfunctional.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix asic gfx values for scrapper asics

2014-01-09T20:24:22+00:00

commit e2f6c88fb903e123edfd1106b0b8310d5117f774 upstream.

Fixes gfx corruption on certain TN/RL parts.

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

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

drm/i915: don't update the dri1 breadcrumb with modesetting

2014-01-09T20:24:22+00:00

commit 6c719faca2aceca72f1bf5b1645c1734ed3e9447 upstream.

The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.

Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.

Note that the race is fairly easy to hit since we call the breadcrumb
function for any interrupt. So the vblank interrupt (which usually
keeps going for a bit) is enough. But even if we'd block this and only
update the breadcrumb for user interrupts from the CS we could hit
this race with kms/gem userspace: If a non-master is waiting somewhere
(and hence has interrupts enabled) and the master closes its fd
(probably due to crashing).

v2: Add a code comment to explain why fixing this for real isn't
really worth it. Also improve the commit message a bit.

v3: Fix the spelling in the comment.

Reported-by: Eugene Shatokhin 
Cc: Eugene Shatokhin 
Acked-by: Chris Wilson 
Tested-by: Eugene Shatokhin 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Hold mutex across i915_gem_release

2014-01-09T20:24:22+00:00

commit 0d1430a3f4b7cfd8779b78740a4182321f3ca7f3 upstream.

Inorder to serialise the closing of the file descriptor and its
subsequent release of client requests with i915_gem_free_request(), we
need to hold the struct_mutex in i915_gem_release(). Failing to do so
has the potential to trigger an OOPS, later with a use-after-free.

Testcase: igt/gem_close_race
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70874
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71029
Reported-by: Eric Anholt 
Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Take modeset locks around intel_modeset_setup_hw_state()

2014-01-09T20:24:21+00:00

commit 027476642811f8559cbe00ef6cc54db230e48a20 upstream.

Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the locks, but the init codepath
doesn't, so fix that.

Note: This slipped through since we only disable pipes if the
plane/pipe linking doesn't match. Which is only relevant on older
gen3 mobile machines, if the BIOS fails to set up our preferred
linking.

Signed-off-by: Ville Syrjälä 
Tested-and-reported-by: Paul Bolle 
[danvet: Add note now that I could confirm my theory with the log
files Paul Bolle provided.]
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman