summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2013-10-01drm/radeon: avoid UVD corruptions on AGP cardsChristian König
commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream. Putting everything into VRAM seems to help. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon: fix panel scaling with eDP and LVDS bridgesAlex Deucher
commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream. We were using the wrong set_properly callback so we always ended up with Full scaling even if something else (Center or Full aspect) was selected. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2)Alex Deucher
commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream. The OUTPUT_ENABLE action jumps past the point in the coder where the data_offset is set on certain rs780 cards. This worked previously because the OUTPUT_ENABLE action is always called immediately after the ENABLE action so the data_offset remained set. In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57 (drm/radeon/atom: initialize more atom interpretor elements to 0), we explictly reset data_offset to 0 between atom calls which then caused this to fail. The fix is to just skip calling the OUTPUT_ENABLE action on the problematic chipsets. The ENABLE action does the same thing and more. Ultimately, we could probably drop the OUTPUT_ENABLE action all together on DCE3 asics. fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60791 v2: only rs880 seems to be affected Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon: fix handling of variable sized arrays for router objectsAlex Deucher
commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream. The table has the following format: typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset pointing to this structure { UCHAR ucNumberOfSrc; USHORT usSrcObjectID[1]; UCHAR ucNumberOfDst; USHORT usDstObjectID[1]; }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT; usSrcObjectID[] and usDstObjectID[] are variably sized, so we can't access them directly. Use pointers and update the offset appropriately when accessing the Dst members. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon: fix resume on some rs4xx boards (v2)Alex Deucher
commit acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream. Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on some boards on resume. The systems seem to work fine without touching this bit so leave it as is. v2: read-modify-write the GART_INDEX_REG_EN bit. I suspect the problem is that we are losing the other settings in the register. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=52952 Reported-by: Ondrej Zary <linux@rainbow-software.org> Tested-by: Daniel Tobias <dan.g.tob@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon: update line buffer allocation for dce6Alex Deucher
commit 290d24576ccf1aa0373d2185cedfe262d0d4952a upstream. We need to allocate line buffer to each display when setting up the watermarks. Failure to do so can lead to a blank screen. This fixes blank screen problems on dce6 asics. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=64850 Based on an initial fix from: Jay Cornwall <jay.cornwall@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon: update line buffer allocation for dce4.1/5Alex Deucher
commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream. We need to allocate line buffer to each display when setting up the watermarks. Failure to do so can lead to a blank screen. This fixes blank screen problems on dce4.1/5 asics. Based on an initial fix from: Jay Cornwall <jay.cornwall@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon/si: Add support for CP DMA to CS checker for compute v2Tom Stellard
commit e5b9e7503eb1f4884efa3b321d3cc47806779202 upstream. Also add a new RADEON_INFO query to check that CP DMA packets are supported on the compute ring. CP DMA has been supported since the 3.8 kernel, but due to an oversight we forgot to teach the CS checker that the CP DMA packet was legal for the compute ring on Southern Islands GPUs. This patch fixes a bug where the radeon driver will incorrectly reject a legal CP DMA packet from user space. I would like to have the patch backported to stable so that we don't have to require Mesa users to use a bleeding edge kernel in order to take advantage of this feature which is already present in the stable kernels (3.8 and newer). v2: - Don't bump kms version, so this patch can be backported to stable kernels. Signed-off-by: Tom Stellard <thomas.stellard@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon: fix endian bugs in hw i2c atom routinesAlex Deucher
commit 4543eda52113d1e2cc0e9bf416f79597e6ef1ec7 upstream. Need to swap the data fetched over i2c properly. This is the same fix as the endian fix for aux channel transactions. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/radeon: fix LCD record parsingAlex Deucher
commit 95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream. If the LCD table contains an EDID record, properly account for the edid size when walking through the records. This should fix error messages about unknown LCD records. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/nv50/disp: prevent false output detection on the original nv50Emil Velikov
commit 5087f51da805f53cba7366f70d596e7bde2a5486 upstream. Commit ea9197cc323839ef3d5280c0453b2c622caa6bc7 effectively enabled the use of an improved DAC detection code, but introduced a regression on the original nv50 chipset, causing a ghost monitor to be detected. v2 (Ben Skeggs): the offending line was likely a thinko, removed it for all chipsets (tested nv50 and nve6 to cover entire range) and added some additional debugging. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67382 Tested-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/ttm: fix the tt_populated check in ttm_tt_destroy()Ben Skeggs
commit 182b17c8dc4e83aab000ce86587b6810e515da87 upstream. After a vmalloc failure in ttm_dma_tt_alloc_page_directory(), ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up inside the driver's unpopulate() hook when populate() has never yet been called. On nouveau, the first issue to be hit because of this is that dma_address[] may be a NULL pointer. After working around this, ttm_pool_unpopulate() may potentially hit the same issue with the pages[] array. It seems to make more sense to avoid calling unpopulate on already unpopulated TTMs than to add checks to all the implementations. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Cc: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/ast: fix the ast open key functionDave Airlie
commit 2e8378136f28bea960cec643d3fa5d843c9049ec upstream. When porting from UMS I mistyped this from the wrong place, AST noticed and pointed it out, so we should fix it to be like the X.org driver. Reported-by: Y.C. Chen <yc_chen@aspeedtech.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm: fix DRM_IOCTL_MODE_GETFB handle-leakDavid Herrmann
commit 101b96f32956ee99bf1468afaf572b88cda9f88b upstream. DRM_IOCTL_MODE_GETFB is used to retrieve information about a given framebuffer ID. It is a read-only helper and was thus declassified for unprivileged access in: commit a14b1b42477c5ef089fcda88cbaae50d979eb8f9 Author: Mandeep Singh Baines <mandeep.baines@gmail.com> Date: Fri Jan 20 12:11:16 2012 -0800 drm: remove master fd restriction on mode setting getters However, alongside width, height and stride information, DRM_IOCTL_MODE_GETFB also passes back a handle to the underlying buffer of the framebuffer. This handle allows users to mmap() it and read or write into it. Obviously, this should be restricted to DRM-Master. With the current setup, *any* process with access to /dev/dri/card0 (which means any process with access to hardware-accelerated rendering) can access the current screen framebuffer and modify it ad libitum. For backwards-compatibility reasons we want to keep the DRM_IOCTL_MODE_GETFB call unprivileged. Besides, it provides quite useful information regarding screen setup. So we simply test whether the caller is the current DRM-Master and if not, we return 0 as handle, which is always invalid. A following DRM_IOCTL_GEM_CLOSE on this handle will fail with EINVAL, but we accept this. Users shouldn't test for errors during GEM_CLOSE, anyway. And it is still better as a failing MODE_GETFB call. v2: add capable(CAP_SYS_ADMIN) check for compatibility with i-g-t Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/i915: fix wait_for_pending_flips vs gpu hang deadlockDaniel Vetter
commit 17e1df07df0fbc77696a1e1b6ccf9f2e5af70e40 upstream. My g33 here seems to be shockingly good at hitting them all. This time around kms_flip/flip-vs-panning-vs-hang blows up: intel_crtc_wait_for_pending_flips correctly checks for gpu hangs and if a gpu hang is pending aborts the wait for outstanding flips so that the setcrtc call will succeed and release the crtc mutex. And the gpu hang handler needs that lock in intel_display_handle_reset to be able to complete outstanding flips. The problem is that we can race in two ways: - Waiters on the dev_priv->pending_flip_queue aren't woken up after we've the reset as pending, but before we actually start the reset work. This means that the waiter doesn't notice the pending reset and hence will keep on hogging the locks. Like with dev->struct_mutex and the ring->irq_queue wait queues we there need to wake up everyone that potentially holds a lock which the reset handler needs. - intel_display_handle_reset was called _after_ we've already signalled the completion of the reset work. Which means a waiter could sneak in, grab the lock and never release it (since the pageflips won't ever get released). Similar to resetting the gem state all the reset work must complete before we update the reset counter. Contrary to the gem reset we don't need to have a second explicit wake up call since that will have happened already when completing the pageflips. We also don't have any issues that the completion happens while the reset state is still pending - wait_for_pending_flips is only there to ensure we display the right frame. After a gpu hang&reset events such guarantees are out the window anyway. This is in contrast to the gem code where too-early wake-up would result in unnecessary restarting of ioctls. Also, since we've gotten these various deadlocks and ordering constraints wrong so often throw copious amounts of comments at the code. This deadlock regression has been introduced in the commit which added the pageflip reset logic to the gpu hang work: commit 96a02917a0131e52efefde49c2784c0421d6c439 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Feb 18 19:08:49 2013 +0200 drm/i915: Finish page flips and update primary planes after a GPU reset v2: - Add comments to explain how the wake_up serves as memory barriers for the atomic_t reset counter. - Improve the comments a bit as suggested by Chris Wilson. - Extract the wake_up calls before/after the reset into a little i915_error_wake_up and unconditionally wake up the pending_flip_queue waiters, again as suggested by Chris Wilson. v3: Throw copious amounts of comments at i915_error_wake_up as suggested by Chris Wilson. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-10-01drm/i915: fix gpu hang vs. flip stall deadlocksDaniel Vetter
commit 122f46badaafbe651f05c2c0f24cadee692f761b upstream. Since we've started to clean up pending flips when the gpu hangs in commit 96a02917a0131e52efefde49c2784c0421d6c439 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Feb 18 19:08:49 2013 +0200 drm/i915: Finish page flips and update primary planes after a GPU reset the gpu reset work now also grabs modeset locks. But since work items on our private work queue are not allowed to do that due to the flush_workqueue from the pageflip code this results in a neat deadlock: INFO: task kms_flip:14676 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kms_flip D ffff88019283a5c0 0 14676 13344 0x00000004 ffff88018e62dbf8 0000000000000046 ffff88013bdb12e0 ffff88018e62dfd8 ffff88018e62dfd8 00000000001d3b00 ffff88019283a5c0 ffff88018ec21000 ffff88018f693f00 ffff88018eece000 ffff88018e62dd60 ffff88018eece898 Call Trace: [<ffffffff8138ee7b>] schedule+0x60/0x62 [<ffffffffa046c0dd>] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915] [<ffffffff81050ff4>] ? finish_wait+0x60/0x60 [<ffffffffa0478041>] intel_crtc_set_config+0x7f3/0x81e [i915] [<ffffffffa031780a>] drm_mode_set_config_internal+0x4f/0xc6 [drm] [<ffffffffa0319cf3>] drm_mode_setcrtc+0x44d/0x4f9 [drm] [<ffffffff810e44da>] ? might_fault+0x38/0x86 [<ffffffffa030d51f>] drm_ioctl+0x2f9/0x447 [drm] [<ffffffff8107a722>] ? trace_hardirqs_off+0xd/0xf [<ffffffffa03198a6>] ? drm_mode_setplane+0x343/0x343 [drm] [<ffffffff8112222f>] ? mntput_no_expire+0x3e/0x13d [<ffffffff81117f33>] vfs_ioctl+0x18/0x34 [<ffffffff81118776>] do_vfs_ioctl+0x396/0x454 [<ffffffff81396b37>] ? sysret_check+0x1b/0x56 [<ffffffff81118886>] SyS_ioctl+0x52/0x7d [<ffffffff81396b12>] system_call_fastpath+0x16/0x1b 2 locks held by kms_flip/14676: #0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa0316545>] drm_modeset_lock_all+0x22/0x59 [drm] #1: (&crtc->mutex){+.+.+.}, at: [<ffffffffa031656b>] drm_modeset_lock_all+0x48/0x59 [drm] INFO: task kworker/u8:4:175 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u8:4 D ffff88018de9a5c0 0 175 2 0x00000000 Workqueue: i915 i915_error_work_func [i915] ffff88018e37dc30 0000000000000046 ffff8801938ab8a0 ffff88018e37dfd8 ffff88018e37dfd8 00000000001d3b00 ffff88018de9a5c0 ffff88018ec21018 0000000000000246 ffff88018e37dca0 000000005a865a86 ffff88018de9a5c0 Call Trace: [<ffffffff8138ee7b>] schedule+0x60/0x62 [<ffffffff8138f23d>] schedule_preempt_disabled+0x9/0xb [<ffffffff8138d0cd>] mutex_lock_nested+0x205/0x3b1 [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa044e0a2>] i915_error_work_func+0x128/0x147 [i915] [<ffffffff8104a89a>] process_one_work+0x1d4/0x35a [<ffffffff8104a821>] ? process_one_work+0x15b/0x35a [<ffffffff8104b4a5>] worker_thread+0x144/0x1f0 [<ffffffff8104b361>] ? rescuer_thread+0x275/0x275 [<ffffffff8105076d>] kthread+0xac/0xb4 [<ffffffff81059d30>] ? finish_task_switch+0x3b/0xc0 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60 [<ffffffff81396a6c>] ret_from_fork+0x7c/0xb0 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60 3 locks held by kworker/u8:4/175: #0: (i915){.+.+.+}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a #1: ((&dev_priv->gpu_error.work)){+.+.+.}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a #2: (&crtc->mutex){+.+.+.}, at: [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915] This blew up while running kms_flip/flip-vs-panning-vs-hang-interruptible on one of my older machines. Unfortunately (despite the proper lockdep annotations for flush_workqueue) lockdep still doesn't detect this correctly, so we need to rely on chance to discover these bugs. Apply the usual bugfix and schedule the reset work on the system workqueue to keep our own driver workqueue free of any modeset lock grabbing. Note that this is not a terribly serious regression since before the offending commit we'd simply have stalled userspace forever due to failing to abort all outstanding pageflips. v2: Add a comment as requested by Chris. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-26drm/edid: add quirk for Medion MD30217PGAlex Deucher
commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream. This LCD monitor (1280x1024 native) has a completely bogus detailed timing (640x350@70hz). User reports that 1280x1024@60 has waves so prefer 1280x1024@75. Manufacturer: MED Model: 7b8 Serial#: 99188 Year: 2005 Week: 5 EDID Version: 1.3 Analog Display Input, Input Voltage Level: 0.700/0.700 V Sync: Separate Max Image Size [cm]: horiz.: 34 vert.: 27 Gamma: 2.50 DPMS capabilities: Off; RGB/Color Display First detailed timing is preferred mode redX: 0.645 redY: 0.348 greenX: 0.280 greenY: 0.605 blueX: 0.142 blueY: 0.071 whiteX: 0.313 whiteY: 0.329 Supported established timings: 720x400@70Hz 640x480@60Hz 640x480@72Hz 640x480@75Hz 800x600@56Hz 800x600@60Hz 800x600@72Hz 800x600@75Hz 1024x768@60Hz 1024x768@70Hz 1024x768@75Hz 1280x1024@75Hz Manufacturer's mask: 0 Supported standard timings: Supported detailed timing: clock: 25.2 MHz Image Size: 337 x 270 mm h_active: 640 h_sync: 688 h_sync_end 784 h_blank_end 800 h_border: 0 v_active: 350 v_sync: 350 v_sync_end 352 v_blanking: 449 v_border: 0 Monitor name: MD30217PG Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz Serial No: 501099188 EDID (in hex): 00ffffffffffff0034a4b80774830100 050f010368221b962a0c55a559479b24 125054afcf00310a0101010101018180 000000000000d60980a0205e63103060 0200510e1100001e000000fc004d4433 3032313750470a202020000000fd0038 4c1e530e000a202020202020000000ff 003530313039393138380a2020200078 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reported-by: friedrich@mailstation.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-07drm/i915: ivb: fix edp voltage swing reg valImre Deak
commit 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d upstream. Fix the typo introduced in commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85 Author: Keith Packard <keithp@keithp.com> Date: Wed Nov 16 16:26:07 2011 -0800 drm/i915: Hook up Ivybridge eDP This fixes eDP link-training failures and cases where all voltage swing /pre-emphasis levels were tried and failed during clock recovery and - as a fallback - we go on to do channel equalization with the last voltage swing/pre-emphasis level which will succeed. Both issues can lead to a blank screen. v2: - improve commit message Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880 Tested-by: Jeremy Moles <cubicool@gmail.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-07drm/vmwgfx: Split GMR2_REMAP commands if they are to largeJakob Bornecrantz
commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f upstream. This fixes the piglit test texturing/max-texture-size causing the VM to die due to a too large SVGA command. Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Biran Paul <brianp@vmware.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-09-07drm/nouveau/mc: fix race condition between constructor and request_irq()Ben Skeggs
commit 6ff8c76a566f823d796359a6c1d76b7668f1e34d upstream. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29drm/i915: Invalidate TLBs for the rings after a resetChris Wilson
commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream. After any "soft gfx reset" we must manually invalidate the TLBs associated with each ring. Empirically, it seems that a suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is that the hardware would fail to note the new address for its status page, and so it would continue to write the shadow registers and breadcrumbs into the old physical address (now used by something completely different, scary). Whereas the driver would read the new status page and never see any progress, it would appear that the GPU hung immediately upon resume. Based on a patch by naresh kumar kachhi <naresh.kumar.kacchi@intel.com> Reported-by: Thiago Macieira <thiago@kde.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thiago Macieira <thiago@kde.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29drm/radeon: fix WREG32_OR macro setting bits in a registerRafał Miłecki
commit d43a93c8d9bc4e0dc0293b6458c077c3c797594f upstream. This bug (introduced in 3.10) in WREG32_OR made commit d3418eacad403033e95e49dc14afa37c2112c134 "drm/radeon/evergreen: setup HDMI before enabling it" cause a regression. Sometimes audio over HDMI wasn't working, sometimes display was corrupted. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60687 https://bugzilla.kernel.org/show_bug.cgi?id=60709 https://bugs.freedesktop.org/show_bug.cgi?id=67767 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29drm/radeon: fix UVD message buffer validationChristian König
commit 112a6d0c071808f6d48354fc8834a574e5dcefc0 upstream. When the message buffer is currently moving block until it is idle again. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-29drm/radeon/r7xx: fix copy paste typo in golden register setupAlex Deucher
commit 022374c02e357ac82e98dd2689fb2efe05723d69 upstream. Uses the wrong array size for some asics which can lead to garbage getting written to registers. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60674 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/radeon: always program the MC on startupAlex Deucher
commit 6fab3febf6d949b0a12b1e4e73db38e4a177a79e upstream. For r6xx+ asics. This mirrors the behavior of pre-r6xx asics. We need to program the MC even if something else in startup() fails. Failure to do so results in an unusable GPU. Based on a fix from: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> [ rebased for 3.10 and dropped the drivers/gpu/drm/radeon/cik.c bit as it's 3.11 specific code / tmb ] Signed-off-by: Thomas Backlund <tmb@mageia.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/radeon: only save UVD bo when we have open handlesChristian König
commit 4ad9c1c774c2af152283f510062094e768876f55 upstream. Otherwise just reinitialize from scratch on resume, and so make it more likely to succeed. v2: rebased for 3.10-stable tree Signed-off-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/radeon: fix halting UVDChristian König
commit 2858c00d2823c83acce2a1175dbabb2cebee8678 upstream. Removing the clock/power or resetting the VCPU can cause hangs if that happens in the middle of a register write. Stall the memory and register bus before putting the VCPU into reset. Keep it in reset when unloading the module or suspending. v2: rebased on 3.10-stable tree Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/i915: initialize gt_lock early with other spin locksJani Nikula
commit 14c5cec5d0cd73e7e9d4fbea2bbfeea8f3ade871 upstream. commit 181d1b9e31c668259d3798c521672afb8edd355c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 21 13:16:24 2013 +0200 drm/i915: fix up gt init sequence fallout moved dev_priv->gt_lock initialization after use. Do the initialization much earlier with other spin lock initializations. Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Zhouping Liu <zliu@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/radeon: stop sending invalid UVD destroy msgChristian König
commit 641a00593f7d07eab778fbabf546fb68fff3d5ce upstream. We also need to check the handle. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/radeon: select audio dto based on encoder id for DCE3Alex Deucher
commit e1accbf0543eecfdb161131208c3dfefee22d61f upstream. There are two audio dtos on radeon asics that you can select between. Normally, dto0 is used for hdmi and dto1 for DP, but it seems that the dto is somehow tied to the encoders on DCE3 asics. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67435 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm: Don't pass negative delta to ktime_sub_ns()Michel Dänzer
commit e91abf80a0998f326107874c88d549f94839f13c upstream. It takes an unsigned value. This happens not to blow up on 64-bit architectures, but it does on 32-bit, causing drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus timestamps for vblank events. Which in turn causes e.g. gnome-shell to hang after a DPMS off cycle with current xf86-video-ati Git. [airlied: regression introduced in drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59836 Tested-by: shui yangwei <yangweix.shui@intel.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/ast: invalidate page tables when pinning a BODave Airlie
commit 3ac65259328324de323dc006b52ff7c1a5b18d19 upstream. same fix as cirrus and mgag200. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/mgag200: Invalidate page tables when pinning a BOEgbert Eich
commit ecaac1c866bcda4780a963b3d18cd310d971aea3 upstream. When a BO gets pinned the placement may get changed. If the memory is mapped into user space and user space has already accessed the mapped range the page tables are set up but now point to the wrong memory. Set bo.mdev->dev_mapping in mgag200_bo_create() to make sure that ttm_bo_unmap_virtual() called from ttm_bo_handle_move_mem() will take care of this. v2: Don't call ttm_bo_unmap_virtual() in mgag200_bo_pin(), fix comment. Signed-off-by: Egbert Eich <eich@suse.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-14drm/cirrus: Invalidate page tables when pinning a BOMichal Srb
commit 109a51598869a39fdcec2d49672a9a39b6d89481 upstream. This is a cirrus version of Egbert Eich's patch for mgag200. Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked called from ttm_bo_handle_move_mem returns with no effect. If any application accessed the memory before it was moved, it will access wrong memory next time. This causes crashes when changing resolution down. Signed-off-by: Michal Srb <msrb@suse.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11drm/i915: make SDVO TV-out work for multifunction devicesDaniel Vetter
commit 09ede5414f0215461c933032630bf9c3a61a8ba3 upstream. We need to track this correctly. While at it shovel the boolean to track whether the sdvo is in tv mode or not into pipe_config. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997 Tested-by: Pierre Assal <pierre.assal@verint.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63609 Tested-by: cancan,feng <cancan.feng@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11drm/radeon: never unpin UVD bo v3Christian König
commit 9cc2e0e9f13315559c85c9f99f141e420967c955 upstream. Changing the UVD BOs offset on suspend/resume doesn't work because the VCPU internally keeps pointers to it. Just keep it always pinned and save the content manually. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425 v2: fix compiler warning v3: fix CIK support v4: rebased for 3.10-stable tree Note: a version of this patch needs to go to stable. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11drm/i915: Preserve the DDI_A_4_LANES bit from the biosStéphane Marchesin
commit bcf53de4e60d9000b82f541d654529e2902a4c2c upstream. Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes on eDP. This fixes eDP on hsw with > 2 lanes. Also s/port_reversal/saved_port_bits/ since the current name is confusing. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Zhouping Liu <zliu@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11drm/radeon: Disable dma rings for bo moves on r6xxAlex Deucher
commit aeea40cbf9388fc829e66fa049f64d97fd72e118 upstream. They still seem to cause instability on some r6xx parts. As a follow up, we can switch to using CP DMA for bo moves on r6xx as a lighter weight alternative to using the 3D engine. A version of this patch should also go to stable kernels. Tested-by: J.N. <golden.fleeced@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_listXiong Zhang
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 <daniel.vetter@ffwll.ch> 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 <xiong.y.zhang@intel.com> [danvet: Add regression notice.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zhouping Liu <zliu@redhat.com>
2013-08-04radeon kms: do not flush uninitialized hotplug workSergey Senozhatsky
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] [<ffffffff8160434e>] dump_stack+0x4e/0x82 [ 4.795731] [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30 [ 4.795893] [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60 [ 4.796034] [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200 [ 4.796216] [<ffffffff8106cd75>] ? flush_work+0x5/0x280 [ 4.796375] [<ffffffff8106cdad>] flush_work+0x3d/0x280 [ 4.796520] [<ffffffff8106cd75>] ? flush_work+0x5/0x280 [ 4.796682] [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 4.796862] [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0 [ 4.797024] [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70 [ 4.797186] [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0 [ 4.797347] [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700 [ 4.797511] [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50 [ 4.797672] [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150 [ 4.797843] [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280 [ 4.798007] [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0 [ 4.798168] [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0 [ 4.798329] [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0 [ 4.798489] [<ffffffff81339404>] pci_device_probe+0x84/0xe0 [ 4.798644] [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240 [ 4.798805] [<ffffffff814aca73>] __driver_attach+0x93/0xa0 [ 4.798948] [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40 [ 4.799126] [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0 [ 4.799272] [<ffffffff814ac2be>] driver_attach+0x1e/0x20 [ 4.799434] [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280 [ 4.799596] [<ffffffff814ad0e4>] driver_register+0x74/0x150 [ 4.799758] [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60 [ 4.799936] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67 [ 4.800081] [<ffffffff813ce655>] drm_pci_init+0x115/0x130 [ 4.800243] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67 [ 4.800405] [<ffffffff81d16f98>] radeon_init+0x9c/0xba [ 4.800586] [<ffffffff810002ca>] do_one_initcall+0xfa/0x150 [ 4.800746] [<ffffffff81073f60>] ? parse_args+0x120/0x330 [ 4.800909] [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191 [ 4.801052] [<ffffffff81cda87a>] ? do_early_param+0x88/0x88 [ 4.801233] [<ffffffff815fb670>] ? rest_init+0x140/0x140 [ 4.801393] [<ffffffff815fb67e>] kernel_init+0xe/0x180 [ 4.801556] [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0 [ 4.801718] [<ffffffff815fb670>] ? rest_init+0x140/0x140 Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/radeon/atom: initialize more atom interpretor elements to 0Alex Deucher
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 <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/radeon: fix audio dto programming on DCE4+Alex Deucher
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 <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/nouveau: fix semaphore dmabuf objMaarten Lankhorst
commit 7a7da592cbb22a1d360638dbecc393470c5effe3 upstream. Fixes some dmabuf object errors on nv50 chipset and below. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: fix missed hunk after GT access breakageBen Widawsky
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 <chris@chris-wilson.co.uk> 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 <daniel.vetter@ffwll.ch> Date: Sun Jul 21 13:16:24 2013 +0200 drm/i915: fix up gt init sequence fallout Reported-by: Dave Jones <davej@redhat.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: fix up gt init sequence falloutDaniel Vetter
commit 181d1b9e31c668259d3798c521672afb8edd355c upstream. The regression fix for gen6+ rps fallout commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 Author: Konstantin Khlebnikov <khlebnikov@openvz.org> 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 <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: Serialize almost all register accessChris Wilson
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 <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlightKamal Mostafa
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 <EGriffith92@gmail.com> Tested-by: Kent Baxley <kent.baxley@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: correctly restore fences with objects attachedDaniel Vetter
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 <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk> Cc: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Matthew Garrett <matthew.garrett@nebula.com> Tested-by: Björn Bidar <theodorstormgrade@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off()Chris Wilson
commit 2e57f47d317dd035b18634b0c602272529368fcc upstream. In commit e3de42b68478a8c95dd27520e9adead2af9477a5 Author: Imre Deak <imre.deak@intel.com> Date: Fri May 3 19:44:07 2013 +0200 drm/i915: force full modeset if the connector is in DPMS OFF mode a new function was added that walked over the set of connectors to see if any of the currently associated CRTC was switched off. This function walked an array of connectors, rather than the array of pointers to connectors contained in the drm_mode_set - i.e. it was dereferencing far past the end of the first connector. This only becomes an issue if we attempt to use a clone mode (i.e. more than one connector per CRTC) such that set->num_connectors > 1. Reported-by: Timo Aaltonen <tjaalton@ubuntu.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Egbert Eich <eich@suse.de> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: fix long-standing SNB regression in power consumption after resume v2Konstantin Khlebnikov
commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 upstream. This patch fixes regression in power consumtion of sandy bridge gpu, which exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that it's extremely busy. After that it never reaches rc6 state. Bug exists since kernel v3.6: commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 14 11:04:48 2012 -0700 drm/i915: load boot context at driver init time For some reason RC6 is already enabled at the beginning of resuming process. Following initliaztion breaks some internal state and confuses RPS engine. This patch disables RC6 at the beginnig of resume and initialization. I've rearranged initialization sequence, because intel_disable_gt_powersave() needs initialized force_wake_get/put and some locks from the dev_priv. Note: The culprit in the initialization sequence seems to be the write to MBCTL added in the above mentioned commit. The first version of this patch just held a forcewake reference across the clock gating init functions, which seems to have been enought to gather quite a few positive test reports. But since that smelled a bit like ad-hoc duct-tape v2 now just disables rps/rc6 across the entire hw setup. [danvet: Add note about v1 vs. v2 of this patch and use standard layout for the commit citation. Also add the tested-bys from v1 and a cc: stable.] References https://bugs.freedesktop.org/show_bug.cgi?id=54089 References https://bugzilla.kernel.org/show_bug.cgi?id=58971 References https://patchwork.kernel.org/patch/2827634/ (patch v1) Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1) Tested-by: rocko <rockorequin@hotmail.com> (v1) Tested-by: JohnMB <johnmbryant@sky.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-11-20 14:59:35 +0000