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

drm/i915: use in_interrupt() not in_irq() to check context

2015-03-26T12:59:51+00:00

commit 6c51d46f135b00c00373fcd029786ccef2b02b5b upstream.

The kernel in_irq() function tests for hard-IRQ context only, so if a
system is run with the kernel 'threadirqs' option selected, the test in
intel_check_page_flip() generates lots of warnings, because then it gets
called in soft-IRQ context.

We can instead use in_interrupt() which allows for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321
Signed-off-by: Dave Gordon 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Cc: Josh Boyer 
Signed-off-by: Greg Kroah-Hartman

drm/i915: gen4: work around hang during hibernation

2015-03-26T12:59:46+00:00

commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb upstream.

Bjørn reported that his machine hang during hibernation and eventually
bisected the problem to the following commit:

commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak 
Date:   Thu Oct 23 19:23:26 2014 +0300

    drm/i915: add poweroff_late handler

The problem seems to be that after the kernel puts the device into D3
the BIOS still tries to access it, or otherwise assumes that it's in D0.
This is clearly bogus, since ACPI mandates that devices are put into D3
by the OSPM if they are not wake-up sources. In the future we want to
unify more of the driver's runtime and system suspend paths, for example
by skipping all the system suspend/hibernation hooks if the device is
runtime suspended already. Accordingly for all other platforms the goal
is still to properly power down the device during hibernation.

v2:
- Another GEN4 Lenovo laptop had the same issue, while platforms from
  other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
  to work fine. Based on this apply the workaround on all GEN4 Lenovo
  platforms.
- add code comment about failing platforms (Ville)

Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
Reported-and-bisected-by: Bjørn Mork 
Signed-off-by: Imre Deak 
Acked-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: add dev_to_i915 helper

2015-03-26T12:59:46+00:00

commit 888d0d421663313739a8bf93459c6ba61fd4b121 upstream.

This will be needed by later patches, so factor it out.

No functional change.

v2:
- s/dev_to_i915_priv/dev_to_i915/ (Jani)
- don't use the helper in i915_pm_suspend (Chris)
- simplify the helper (Chris)
v3:
- remove redundant upcasting in the helper (Daniel)

Signed-off-by: Imre Deak 
Reviewed-by: Takashi Iwai 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm: Don't assign fbs for universal cursor support to files

2015-03-26T12:59:45+00:00

commit 9a6f5130143c17b91e0a3cbf5cc2d8c1e5a80a63 upstream.

The internal framebuffers we create to remap legacy cursor ioctls to
plane operations for the universal plane support shouldn't be linke to
the file like normal userspace framebuffers. This bug goes back to the
original universal cursor plane support introduced in

commit 161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662
Author: Matt Roper 
Date:   Tue Jun 10 08:28:10 2014 -0700

    drm: Support legacy cursor ioctls via universal planes when possible (v4)

The isn't too disastrous since fbs are small, we only create one when the
cursor bo gets changed and ultimately they'll be reaped when the window
server restarts.

Conceptually we'd want to just pass NULL for file_priv when creating it,
but the driver needs the file to lookup the underlying buffer object for
cursor id. Instead let's move the file_priv linking out of
add_framebuffer_internal() into the addfb ioctl implementation, which is
the only place it is needed. And also rename the function for a more
accurate since it only creates the fb, but doesn't add it anywhere.

Signed-off-by: Daniel Vetter  (fix & commit msg)
Signed-off-by: Chris Wilson  (provider of lipstick)
Reviewed-by: Matt Roper 
Cc: Ville Syrjälä 
Cc: Matt Roper 
Cc: Rob Clark 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix a couple of lock dependency violations

2015-03-26T12:59:45+00:00

commit 5151adb37a5918957f4c33a8d8e7629c0fb00563 upstream.

Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.

Acked-by: Sinclair Yeh 
Signed-off-by: Thomas Hellstrom 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Reorder device takedown somewhat

2015-03-26T12:59:45+00:00

commit 3458390b9f0ba784481d23134798faee27b5f16f upstream.

To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: drop ttm two ended allocation

2015-03-26T12:59:38+00:00

commit a239118a24b3bf9089751068e431dfb63dc4168b upstream.

radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false.  It only took effect when buffers
were validated later.  It also seemed to regress suspend
and resume on some systems possibly due to it not
taking effect in radeon_bo_create().

radeon_bo_create() and radeon_ttm_placement_from_domain()
need to be reworked substantially for this to be optimally
effective.  Re-enable it at that point.

Noticed-by: Oded Gabbay 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: Changing number of compute pipe lines

2015-03-26T12:59:38+00:00

commit e405ca3a1bf166f741506c07c2a277b5d48af8f7 upstream.

The current CP firmware can handle Usermode Queues only on MEC1.
To reflect this firmware change, this commit reduces number of compute pipelines
to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd).

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix wait to actually occur after the signaling callback

2015-03-26T12:59:38+00:00

commit b6610101718d4ab90d793c482625e98eb1262cad upstream.

A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.

This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed too, to completely flush the writes
before radeon_fence_activity is called in radeon_fence_enable_signaling.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
Signed-off-by: Maarten Lankhorst 
Reported-by: Jon Arne Jørgensen 
Reported-and-tested-by: Gustaw Smolarczyk 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: drop setting UPLL to sleep mode

2015-03-26T12:59:37+00:00

commit a17d4996e051e78d164989b894608cf37cd5110b upstream.

Just keep it working, seems to fix some PLL problems.

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

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