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

drm/radeon: use post-decrement in error handling

2016-03-03T23:06:24+00:00

commit bc3f5d8c4ca01555820617eb3b6c0857e4df710d upstream.

We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.

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

drm/radeon: hold reference to fences in radeon_sa_bo_new

2016-03-03T23:06:23+00:00

commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.

An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.

Based on the analogous fix for amdgpu.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Christian König 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: clean up fujitsu quirks

2016-03-03T23:06:23+00:00

commit 0eb1c3d4084eeb6fb3a703f88d6ce1521f8fcdd1 upstream.

Combine the two quirks.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=109481

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

drm/vmwgfx: respect 'nomodeset'

2016-03-03T23:06:23+00:00

commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 upstream.

Signed-off-by: Rob Clark 
Reviewed-by: Thomas Hellstrom .
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

vgaarb: fix signal handling in vga_get()

2016-03-03T23:06:22+00:00

commit 9f5bd30818c42c6c36a51f93b4df75a2ea2bd85e upstream.

There are few defects in vga_get() related to signal hadning:

  - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
    case;

  - if we found pending signal we must remove ourself from wait queue
    and change task state back to running;

  - -ERESTARTSYS is more appropriate, I guess.

Signed-off-by: Kirill A. Shutemov 
Reviewed-by: David Herrmann 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: fix hotplug race at startup

2016-03-03T23:06:19+00:00

commit 7f98ca454ad373fc1b76be804fa7138ff68c1d27 upstream.

We apparantly get a hotplug irq before we've initialised
modesetting,

[drm] Loading R100 Microcode
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [] __mutex_lock_slowpath+0x23/0x91
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf67402 #111
Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
Workqueue: events radeon_hotplug_work_func [radeon]
task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
EIP: 0060:[] EFLAGS: 00010282 CPU: 0
EIP is at __mutex_lock_slowpath+0x23/0x91
EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
Stack:
 f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
 f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
Call Trace:
 [] ? dequeue_task_fair+0xa4/0xb7
 [] ? mutex_lock+0x9/0xa
 [] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
 [] ? process_one_work+0xfc/0x194
 [] ? worker_thread+0x18d/0x218
 [] ? rescuer_thread+0x1d5/0x1d5
 [] ? kthread+0x7b/0x80
 [] ? ret_from_kernel_thread+0x20/0x30
 [] ? init_completion+0x18/0x18
Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63

Reported-and-Tested-by: Meelis Roos 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ast: Initialized data needed to map fbdev memory

2016-03-03T23:06:18+00:00

commit 28fb4cb7fa6f63dc2fbdb5f2564dcbead8e3eee0 upstream.

Due to a missing initialization there was no way to map fbdev memory.
Thus for example using the Xserver with the fbdev driver failed.
This fix adds initialization for fix.smem_start and fix.smem_len
in the fb_info structure, which fixes this problem.

Requested-by: Benjamin Herrenschmidt 
Signed-off-by: Egbert Eich 
[pulled from SuSE tree by me - airlied]
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

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

2015-11-09T18:12:58+00:00

commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 upstream.

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.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm: Reject DRI1 hw lock ioctl functions for kms drivers

2015-10-22T21:37:51+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

Add radeon suspend/resume quirk for HP Compaq dc5750.

2015-10-01T10:07:30+00:00

commit 09bfda10e6efd7b65bcc29237bee1765ed779657 upstream.

With the radeon driver loaded the HP Compaq dc5750
Small Form Factor machine fails to resume from suspend.
Adding a quirk similar to other devices avoids
the problem and the system resumes properly.

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