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

radeon: Do not directly dereference pointers to BIOS area.

2015-05-09T22:16:33+00:00

commit f2c9e560b406f2f6b14b345c7da33467dee9cdf2 upstream.

Use readb() and memcpy_fromio() accessors instead.

Reviewed-by: Christian König 
Signed-off-by: David S. Miller 
Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/vmwgfx: Reorder device takedown somewhat

2015-05-09T22:16:29+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 
[bwh: Backported to 3.2:
 - Adjust context
 - Only the GMR memory type is used]
Signed-off-by: Ben Hutchings

drm/radeon: fix DRM_IOCTL_RADEON_CS oops

2015-05-09T22:16:23+00:00

commit a28b2a47edcd0cb7c051b445f71a426000394606 upstream.

Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
following oops.

Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().

----------------------------------

 #include 
 #include 
 #include 
 #include 
 #include 

 static const struct drm_radeon_cs cs;

 int main(int argc, char **argv)
 {
         return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs);
 }

----------------------------------

[ttrantal@test2 ~]$ ./main /dev/dri/card0
[   46.904650] BUG: unable to handle kernel NULL pointer dereference at           (null)
[   46.905022] IP: [] list_sort+0x42/0x240
[   46.905022] PGD 68f29067 PUD 688b5067 PMD 0
[   46.905022] Oops: 0002 [#1] SMP
[   46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58
[   46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
[   46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000
[   46.905022] RIP: 0010:[]  [] list_sort+0x42/0x240
[   46.905022] RSP: 0018:ffff880058e67998  EFLAGS: 00010246
[   46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[   46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58
[   46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000
[   46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410
[   46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0
[   46.905022] FS:  00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000
[   46.905022] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0
[   46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[   46.905022] Stack:
[   46.905022]  ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000
[   46.905022]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   46.905022]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   46.905022] Call Trace:
[   46.905022]  [] radeon_cs_parser_fini+0x195/0x220
[   46.905022]  [] radeon_cs_ioctl+0xa9/0x960
[   46.905022]  [] drm_ioctl+0x19c/0x640
[   46.905022]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[   46.905022]  [] ? trace_hardirqs_on+0xd/0x10
[   46.905022]  [] radeon_drm_ioctl+0x46/0x80
[   46.905022]  [] do_vfs_ioctl+0x318/0x570
[   46.905022]  [] ? selinux_file_ioctl+0x56/0x110
[   46.905022]  [] SyS_ioctl+0x81/0xa0
[   46.905022]  [] system_call_fastpath+0x12/0x17
[   46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff
ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7
00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85
[   46.905022] RIP  [] list_sort+0x42/0x240
[   46.905022]  RSP 
[   46.905022] CR2: 0000000000000000
[   47.149253] ---[ end trace 09576b4e8b2c20b8 ]---

Reviewed-by: Christian König 
Signed-off-by: Tommi Rantala 
Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon: do a posting read in evergreen_set_irq

2015-05-09T22:16:23+00:00

commit c320bb5f6dc0cb88a811cbaf839303e0a3916a92 upstream.

To make sure the writes go through the pci bridge.

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

Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon: do a posting read in r600_set_irq

2015-05-09T22:16:23+00:00

commit 9d1393f23d5656cdd5f368efd60694d4aeed81d3 upstream.

To make sure the writes go through the pci bridge.

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

Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon: do a posting read in rs600_set_irq

2015-05-09T22:16:22+00:00

commit 54acf107e4e66d1f4a697e08a7f60dba9fcf07c3 upstream.

To make sure the writes go through the pci bridge.

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

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/radeon: do a posting read in r100_set_irq

2015-05-09T22:16:22+00:00

commit f957063fee6392bb9365370db6db74dc0b2dce0a upstream.

To make sure the writes go through the pci bridge.

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

Signed-off-by: Alex Deucher 
Signed-off-by: Ben Hutchings

drm/radeon/dp: Set EDP_CONFIGURATION_SET for bridge chips if necessary

2015-05-09T22:16:17+00:00

commit 66c2b84ba6256bc5399eed45582af9ebb3ba2c15 upstream.

Don't restrict it to just eDP panels.  Some LVDS bridge chips require
this.  Fixes blank panels on resume on certain laptops.  Noticed
by mrnuke on IRC.

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

Signed-off-by: Alex Deucher 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

drm/i915: Only fence tiled region of object.

2015-02-20T00:49:39+00:00

commit af1a7301c7cf8912dca03065d448c4437c5c239f upstream.

When creating a fence for a tiled object, only fence the area that
makes up the actual tiles.  The object may be larger than the tiled
area and if we allow those extra addresses to be fenced, they'll
get converted to addresses beyond where the object is mapped. This
opens up the possiblity of writes beyond the end of object.

To prevent this, we adjust the size of the fence to only encompass
the area that makes up the actual tiles.  The extra space is considered
un-tiled and now behaves as if it was a linear object.

Testcase: igt/gem_tiled_fence_overflow
Reported-by: Dan Hettena 
Signed-off-by: Bob Paauwe 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
[bwh: Backported to 3.2:
 - Adjust context, indentation
 - Apply to both i965_write_fence_reg() and sandybridge_write_fence_reg(),
   which have been combined into one function upstream]
Signed-off-by: Ben Hutchings

drm/vmwgfx: Don't use memory accounting for kernel-side fence objects

2015-02-20T00:49:29+00:00

commit 1f563a6a46544602183e7493b6ef69769d3d76d9 upstream.

Kernel side fence objects are used when unbinding resources and may thus be
created as part of a memory reclaim operation. This might trigger recursive
memory reclaims and result in the kernel running out of stack space.

So a simple way out is to avoid accounting of these fence objects.
In principle this is OK since while user-space can trigger the creation of
such objects, it can't really hold on to them. However, their lifetime is
quite long, so some form of accounting should perhaps be implemented in the
future.

Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3
with low system memory settings.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
Reviewed-by: Sinclair Yeh 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings