linux.git/drivers/gpu, branch v3.10.100

Revert "drm/radeon: hold reference to fences in radeon_sa_bo_new"

2016-03-09T23:31:56+00:00

This reverts commit 8d5e1e5af0c667545c202e8f4051f77aa3bf31b7 which was
commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb upstream.

It breaks working hardware, a backported version might be provided at
some unknown time in the future.

Reported-by: Erik Andersen 
Acked-by: Christian König 
Cc: Nicolai Hähnle 
Signed-off-by: Greg Kroah-Hartman

drm/ast: Fix incorrect register check for DRAM width

2016-03-09T23:31:54+00:00

commit 2d02b8bdba322b527c5f5168ce1ca10c2d982a78 upstream.

During DRAM initialization on certain ASpeed devices, an incorrect
bit (bit 10) was checked in the "SDRAM Bus Width Status" register
to determine DRAM width.

Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05.

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

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