linux-toradex.git/drivers/gpu, branch v3.10.5

drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list

2013-08-04T08:51:18+00:00

commit 067556084a0e412013af6b0250a3143ae5afde6d upstream.

obj->mm_list link to dev_priv->mm.inactive_list/active_list
obj->global_list link to dev_priv->mm.unbound_list/bound_list

This regression has been introduced in

commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa
Author: Daniel Vetter 
Date:   Thu Jan 10 18:03:00 2013 +0100

    drm/i915: Revert shrinker changes from "Track unbound pages"

Cc: stable@vger.kernel.org
Signed-off-by: Xiong Zhang 
[danvet: Add regression notice.]
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Zhouping Liu

radeon kms: do not flush uninitialized hotplug work

2013-08-04T08:51:17+00:00

commit a01c34f72e7cd2624570818f579b5ab464f93de2 upstream.

Fix a warning from lockdep caused by calling flush_work() for
uninitialized hotplug work. Initialize hotplug_work, audio_work
and reset_work upon successful radeon_irq_kms_init() completion
and thus perform hotplug flush_work only when rdev->irq.installed
is true.

[    4.790019] [drm] Loading CEDAR Microcode
[    4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
[    4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[    4.791330] radeon 0000:01:00.0: disabling GPU acceleration

[    4.792633] INFO: trying to register non-static key.
[    4.792792] the code is fine but needs lockdep annotation.
[    4.792953] turning off the locking correctness validator.

[    4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
[    4.793314] Hardware name: Acer             Aspire 5741G    /Aspire 5741G    , BIOS V1.20 02/08/2011
[    4.793507]  ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002
[    4.794155]  ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000
[    4.794789]  ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000
[    4.795418] Call Trace:
[    4.795573]  [] dump_stack+0x4e/0x82
[    4.795731]  [] __lock_acquire+0x1a64/0x1d30
[    4.795893]  [] ? dev_vprintk_emit+0x50/0x60
[    4.796034]  [] lock_acquire+0xa4/0x200
[    4.796216]  [] ? flush_work+0x5/0x280
[    4.796375]  [] flush_work+0x3d/0x280
[    4.796520]  [] ? flush_work+0x5/0x280
[    4.796682]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[    4.796862]  [] ? delay_tsc+0x95/0xf0
[    4.797024]  [] radeon_irq_kms_fini+0x2b/0x70
[    4.797186]  [] evergreen_init+0x2a9/0x2e0
[    4.797347]  [] radeon_device_init+0x5ef/0x700
[    4.797511]  [] ? pci_find_capability+0x47/0x50
[    4.797672]  [] radeon_driver_load_kms+0x8d/0x150
[    4.797843]  [] drm_get_pci_dev+0x166/0x280
[    4.798007]  [] ? kfree+0xf5/0x2e0
[    4.798168]  [] ? radeon_pci_probe+0x98/0xd0
[    4.798329]  [] radeon_pci_probe+0xaa/0xd0
[    4.798489]  [] pci_device_probe+0x84/0xe0
[    4.798644]  [] driver_probe_device+0x76/0x240
[    4.798805]  [] __driver_attach+0x93/0xa0
[    4.798948]  [] ? __device_attach+0x40/0x40
[    4.799126]  [] bus_for_each_dev+0x6b/0xb0
[    4.799272]  [] driver_attach+0x1e/0x20
[    4.799434]  [] bus_add_driver+0x1f0/0x280
[    4.799596]  [] driver_register+0x74/0x150
[    4.799758]  [] __pci_register_driver+0x5d/0x60
[    4.799936]  [] ? ttm_init+0x67/0x67
[    4.800081]  [] drm_pci_init+0x115/0x130
[    4.800243]  [] ? ttm_init+0x67/0x67
[    4.800405]  [] radeon_init+0x9c/0xba
[    4.800586]  [] do_one_initcall+0xfa/0x150
[    4.800746]  [] ? parse_args+0x120/0x330
[    4.800909]  [] kernel_init_freeable+0x111/0x191
[    4.801052]  [] ? do_early_param+0x88/0x88
[    4.801233]  [] ? rest_init+0x140/0x140
[    4.801393]  [] kernel_init+0xe/0x180
[    4.801556]  [] ret_from_fork+0x7c/0xb0
[    4.801718]  [] ? rest_init+0x140/0x140

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

drm/radeon/atom: initialize more atom interpretor elements to 0

2013-08-04T08:51:14+00:00

commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.

The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base.  While here initialize all the
atom interpretor elements to 0.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60639

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

drm/radeon: fix audio dto programming on DCE4+

2013-08-04T08:51:12+00:00

commit 7d61d835824f73dc4097b51f800382467c8049c5 upstream.

We need to set the dto source before setting the
dividers otherwise we may get stability problems
with the dto leading to audio playback problems.

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

drm/nouveau: fix semaphore dmabuf obj

2013-08-04T08:51:12+00:00

commit 7a7da592cbb22a1d360638dbecc393470c5effe3 upstream.

Fixes some dmabuf object errors on nv50 chipset and below.

Signed-off-by: Maarten Lankhorst 
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix missed hunk after GT access breakage

2013-08-04T08:51:12+00:00

commit e1b4d3036c07ff137955fb1c0197ab62534f46ec upstream.

Upon some code refactoring, a hunk was missed. This was fixed for
next, but missed the current trees, and hasn't yet been merged by Dave
Airlie. It is fixed in:
commit 907b28c56ea40629aa6595ddfa414ec2fc7da41c
Author: Chris Wilson 
Date:   Fri Jul 19 20:36:52 2013 +0100

    drm/i915: Colocate all GT access routines in the same file

It is introduced by:
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter 
Date:   Sun Jul 21 13:16:24 2013 +0200

    drm/i915: fix up gt init sequence fallout

Reported-by: Dave Jones 
Signed-off-by: Ben Widawsky 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: fix up gt init sequence fallout

2013-08-04T08:51:12+00:00

commit 181d1b9e31c668259d3798c521672afb8edd355c upstream.

The regression fix for gen6+ rps fallout

commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505
Author: Konstantin Khlebnikov 
Date:   Wed Jul 17 10:22:58 2013 +0400

    drm/i915: fix long-standing SNB regression in power consumption after resume

unintentionally also changed the init sequence ordering between
gt_init and gt_reset - we need to reset BIOS damage like leftover
forcewake references before we run our own code. Otherwise we can get
nasty dmesg noise like

[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.

again. Since _reset suggests that we first need to have stuff
initialized (which isn't the case here) call it sanitze instead.

While at it also block out the rps disable introduced by the above
commit on ilk: We don't have any knowledge of ilk rps being broken in
similar ways. And the disable functions uses the default hw state
which is only read out when we're enabling rps. So essentially we've
been writing random grabage into that register.

Reported-by: Chris Wilson 
Cc: Chris Wilson 
Cc: Konstantin Khlebnikov 
Cc: Jesse Barnes 
Tested-by: Chris Wilson 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Serialize almost all register access

2013-08-04T08:51:11+00:00

commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a upstream.

In theory, the different register blocks were meant to be only ever
touched when holding either the struct_mutex, mode_config.lock or even a
specific localised lock. This does not seem to be the case, and the
hardware reacts extremely badly if we attempt to concurrently access two
registers within the same cacheline.

The HSD suggests that we only need to do this workaround for display
range registers. However, upon review we need to serialize the multiple
stages in our register write functions - if only for preemption
protection.

Irrespective of the hardware requirements, the current io functions are
a little too loose with respect to the combination of pre- and
post-condition testing that we do in conjunction with the actual io. As
a result, we may be pre-empted and generate both false-postive and
false-negative errors.

Note well that this is a "90%" solution, there remains a few direct
users of ioread/iowrite which will be fixed up in the next few patches.
Since they are more invasive and that this simple change will prevent
almost all lockups on Haswell, we kept this patch simple to facilitate
backporting to stable.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914
Signed-off-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight

2013-08-04T08:51:11+00:00

commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
BugLink: https://bugs.launchpad.net/bugs/1163720
BugLink: https://bugs.launchpad.net/bugs/1162026

Some machines suffer from non-functional backlight controls if
BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so.
Apply this quirk to Dell XPS 13 models.

Tested-by: Eric Griffith 
Tested-by: Kent Baxley 
Signed-off-by: Kamal Mostafa 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman

drm/i915: correctly restore fences with objects attached

2013-08-04T08:51:10+00:00

commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 upstream.

To avoid stalls we delay tiling changes and especially hold of
committing the new fence state for as long as possible.
Synchronization points are in the execbuf code and in our gtt fault
handler.

Unfortunately we've missed that tricky detail when adding proper fence
restore code in

commit 19b2dbde5732170a03bd82cc8bd442cf88d856f7
Author: Chris Wilson 
Date:   Wed Jun 12 10:15:12 2013 +0100

    drm/i915: Restore fences after resume and GPU resets

The result was that we've restored fences for objects with no tiling,
since the object<->fence link still existed after resume. Now that
wouldn't have been too bad since any subsequent access would have
fixed things up, but if we've changed from tiled to untiled real havoc
happened:

The tiling stride is stored -1 in the fence register, so a stride of 0
resulted in all 1s in the top 32bits, and so a completely bogus fence
spanning everything from the start of the object to the top of the
GTT. The tell-tale in the register dumps looks like:

                 FENCE START 2: 0x0214d001
                 FENCE END 2: 0xfffff3ff

Bit 11 isn't set since the hw doesn't store it, even when writing all
1s (at least on my snb here).

To prevent such a gaffle in the future add a sanity check for fences
with an untiled object attached in i915_gem_write_fence.

v2: Fix the WARN, spotted by Chris.

v3: Trying to reuse get_fences looked ugly and obfuscated the code.
Instead reuse update_fence and to make it really dtrt also move the
fence dirty state clearing into update_fence.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
Cc: Chris Wilson 
Cc: Stéphane Marchesin 
Reviewed-by: Chris Wilson 
Tested-by: Matthew Garrett 
Tested-by: Björn Bidar 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman