summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
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>
2013-08-04drm/i915: Fix incoherence with fence updates on Sandybridge+Chris Wilson
commit d18b9619034230b6f945e215276425636ca401fe upstream. This hopefully fixes the root cause behind the workaround added in commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Apr 4 21:31:03 2013 +0100 drm/i915: Workaround incoherence between fences and LLC across multiple CPUs Thanks to further investigation by Jon Bloomfield, he realised that the 64-bit register might be broken up by the hardware into two 32-bit writes (a problem we have encountered elsewhere). This non-atomicity would then cause an issue where a second thread would see an intermediate register state (new high dword, old low dword), and this register would randomly be used in preference to its own thread register. This would cause the second thread to read from and write into a fairly random tiled location. Breaking the operation into 3 explicit 32-bit updates (first disable the fence, poke the upper bits, then poke the lower bits and enable) ensures that, given proper serialisation between the 32-bit register write and the memory transfer, that the fence value is always consistent. Armed with this knowledge, we can explain how the previous workaround work. The key to the corruption is that a second thread sees an erroneous fence register that conflicts and overrides its own. By serialising the fence update across all CPUs, we have a small window where no GTT access is occurring and so hide the potential corruption. This also leads to the conclusion that the earlier workaround was incomplete. v2: Be overly paranoid about the order in which fence updates become visible to the GPU to make really sure that we turn the fence off before doing the update, and then only switch the fence on afterwards. Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Carsten Emde <C.Emde@osadl.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"Guenter Roeck
commit c11e5f35ab490bd30591563816fbc83526521777 upstream. This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for IvyBridge CPUs. The original commit results in repeated 'Timed out waiting for forcewake old ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b) with i7-3770K CPU. It ultimately results in a hangup if the system is highly loaded. Reverting the commit for IvyBridge CPUs fixes the issue. Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since this condition can result in secondary issues. v2: Only revert patch for Ivybridge CPUs Issue info message if mt forcewake is disabled on Ivybridge Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: Fix write-read race with multiple ringsChris Wilson
commit 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 upstream. Daniel noticed a problem where is we wrote to an object with ring A in the middle of a very long running batch, then executed a quick batch on ring B before a batch that reads from the same object, its obj->ring would now point to ring B, but its last_write_seqno would be still relative to ring A. This would allow for the user to read from the object before the GPU had completed the write, as set_domain would only check that ring B had passed the last_write_seqno. To fix this simply (and inelegantly), we bump the last_write_seqno when switching rings so that the last_write_seqno is always relative to the current obj->ring. This fixes igt/tests/gem_write_read_ring_switch. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Add note about the newly created igt which exercises this bug.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/aDaniel Vetter
commit aaf8a5167291b65e9116cb8736d862965b57c13a upstream. It's not a good idea to also run the pipe_control cleanup. This regression has been introduced whith the original cs tlb w/a in commit b45305fce5bb1abec263fcff9d81ebecd6306ede Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 17 16:21:27 2012 +0100 drm/i915: Implement workaround for broken CS tlb on i830/845 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610 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-08-04drm/radeon: improve dac adjust heuristics for legacy pdacAlex Deucher
commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream. Hopefully avoid more quirks in the future due to bogus vbios dac data. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/radeon: fix combios tables on older cardsMark Kettenis
commit cef1d00cd56f600121ad121875655ad410a001b8 upstream. Noticed that my old Radeon 7500 hung after printing drm: GPU not posted. posting now... when it wasn't selected as the primary card the BIOS. Some digging revealed that it was hanging in combios_parse_mmio_table() while parsing the ASIC INIT 3 table. Looking at the BIOS ROM for the card, it becomes obvious that there is no ASIC INIT 3 table in the BIOS. The code is just processing random garbage. No surprise it hangs! Why do I say that there is no ASIC INIT 3 table is the BIOS? This table is found through the MISC INFO table. The MISC INFO table can be found at offset 0x5e in the COMBIOS header. But the header is smaller than that. The COMBIOS header starts at offset 0x126. The standard PCI Data Structure (the bit that starts with 'PCIR') lives at offset 0x180. That means that the COMBIOS header can not be larger than 0x5a bytes and therefore cannot contain a MISC INFO table. I looked at a dozen or so BIOS images, some my own, some downloaded from: <http://www.techpowerup.com/vgabios/index.php?manufacturer=ATI&page=1> It is fairly obvious that the size of the COMBIOS header can be found at offset 0x6 of the header. Not sure if it is a 16-bit number or just an 8-bit number, but that doesn't really matter since the tables seems to be always smaller than 256 bytes. So I think combios_get_table_offset() should check if the requested table is present. This can be done by checking the offset against the size of the header. See the diff below. The diff is against the WIP OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this point. But I don't think this bit of the code changed much since then. For what it is worth: Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/radeon: Another card with wrong primary dac adjOndrej Zary
commit f7929f34fa0e0bb6736a2484fdc07d77a1653081 upstream. Hello, got another card with "too bright" problem: Sapphire Radeon VE 7000 DDR (VGA+S-Video) lspci -vnn: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28] The patch below fixes the problem for this card. But I don't like the blacklist, couldn't some heuristic be used instead? The interesting thing is that the manufacturer is the same as the other card needing the same quirk. I wonder how many different types are broken this way. The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300. ==================== drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR Values from BIOS are wrong, causing too bright colors. Use default values instead. Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/radeon: fix endian issues with DP handling (v3)Alex Deucher
commit 34be8c9af7b8728465963740fc11136ae90dfc36 upstream. The atom interpreter expects data in LE format, so swap the message buffer as apprioriate. v2: properly handle non-dw aligned byte counts. v3: properly handle remainder Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Dong He <hedonghust@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/radeon: allow selection of alignment in the sub-allocatorAlex Deucher
commit 6c4f978b357bc779c703fda1f200e9179623d3e9 upstream. There are cases where we need more than 4k alignment. No functional change with this commit. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/radeon: fix UVD fence emitChristian König
commit c9a6ca4abd5f1978ef15b3ece3474f4372ae5fe7 upstream. Currently doesn't matter cause we allocate the fence in the lower 265MB anyway. Reported-by: Frank Huang <FrankR.Huang@amd.com> 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-04drm/radeon/hdmi: make sure we have an afmt block assignedAlex Deucher
commit c2b4cacfe9816c1fe378c785ce8a678cf0635ec6 upstream. Prevents a segfault if an afmt block is not assigned to the encoder such as in the LVDS or eDP case. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66714 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/nv50-/disp: Use output specific mask in interruptEmil Velikov
commit 378f2bcdf7c971453d11580936dc0ffe845f5880 upstream. The commit commit 476e84e126171d809f9c0b5d97137f5055f95ca8 Author: Ben Skeggs <bskeggs@redhat.com> Date: Mon Feb 11 09:24:23 2013 +1000 drm/nv50-/disp: initial supervisor support for off-chip encoders changed the write mask in one of the interrupt functions for on-chip encoders, causing a regression in certain VGA dual-head setups. This commit reintroduces the mask thus resolving the regression Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66129 Reported-and-Tested-by: Yves-Alexis <corsac@debian.org> CC: Ben Skeggs <bskeggs@redhat.com> 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-07-25drm/nva3/disp: Fix HDMI audio regressionIlia Mirkin
commit bf03d1b293cc556df53545e318110505014d805e upstream. This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix HDMI audio regression). The regression happened as a result of refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into core). Reported-and-tested-by: Max Baldwin <archerseven@gmail.com> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/radeon: add backlight quirk for hybrid macAlex Deucher
commit 80101790670385a85aca35ecae4b89e3f2fceecc upstream. Mac laptops with multiple GPUs apparently use the gmux driver for backlight control. Don't register a radeon backlight interface. We may need to add other pci ids for other hybrid mac laptops. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=65377 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/radeon: fix AVI infoframe generationAlex Deucher
commit f100380ecd8287b0909d3c5694784adc46e78a4a upstream. - remove adding 2 to checksum, this is incorrect. This was incorrectly introduced in: 92db7f6c860b8190571a9dc1fcbc16d003422fe8 http://lists.freedesktop.org/archives/dri-devel/2011-December/017717.html However, the off by 2 was due to adding the version twice. From the examples in the URL above: [Rafał Miłecki][RV620] fglrx: 0x7454: 00 A8 5E 79 R600_HDMI_VIDEOINFOFRAME_0 0x7458: 00 28 00 10 R600_HDMI_VIDEOINFOFRAME_1 0x745C: 00 48 00 28 R600_HDMI_VIDEOINFOFRAME_2 0x7460: 02 00 00 48 R600_HDMI_VIDEOINFOFRAME_3 =================== (0x82 + 0x2 + 0xD) + 0x1F8 = 0x289 -0x289 = 0x77 However, the payload sum is not 0x1f8, it's 0x1f6. 00 + A8 + 5E + 00 + 00 + 28 + 00 + 10 + 00 + 48 + 00 + 28 + 00 + 48 = 0x1f6 Bits 25:24 of HDMI_VIDEOINFOFRAME_3 are the packet version, not part of the payload. So the total would be: (0x82 + 0x2 + 0xD) + 0x1f6 = 0x287 -0x287 = 0x79 - properly emit the AVI infoframe version. This was not being emitted previous which is probably what caused the issue above. This should fix blank screen when HDMI audio is enabled on certain monitors. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/nouveau: use vmalloc for pgt allocationMarcin Slusarz
commit d005f51eb93d71cd40ebd11dd377453fa8c8a42a upstream. Page tables on nv50 take 48kB, which can be hard to allocate in one piece. Let's use vmalloc. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/mgag200: Added resolution and bandwidth limits for various G200e products.Julia Lemire
commit abbee6238775c6633a3779962e9e5b5cb9823749 upstream. At the larger resolutions, the g200e series sometimes struggles with maintaining a proper output. Problems like flickering or black bands appearing on screen can occur. In order to avoid this, limitations regarding resolutions and bandwidth have been added for the different variations of the g200e series. This code was ported from the old xorg mga driver. Signed-off-by: Julia Lemire <jlemire@matrox.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/gem: fix not to assign error value to gem nameYoungJun Cho
commit 2e07fb229396f99fc173d8612f0f83ea9de0341b upstream. If idr_alloc() is failed, obj->name can be error value. Also it cleans up duplicated flink processing code. This regression has been introduced in commit 2e928815c1886fe628ed54623aa98d0889cf5509 Author: Tejun Heo <tj@kernel.org> Date: Wed Feb 27 17:04:08 2013 -0800 drm: convert to idr_alloc() Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.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-07-25drm/i915: Only clear write-domains after a successful wait-seqnoChris Wilson
commit daa13e1ca587bc773c1aae415ed1af6554117bd4 upstream. In the introduction of the non-blocking wait, I cut'n'pasted the wait completion code from normal locked path. Unfortunately, this neglected that the normal path returned early if the wait returned early. The result is that read-only waits may return whilst the GPU is still writing to the bo. Fixes regression from commit 3236f57a0162391f84b93f39fc1882c49a8998c7 [v3.7] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Aug 24 09:35:09 2012 +0100 drm/i915: Use a non-blocking wait for set-to-domain ioctl Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/i915: Fix context sizes on HSWBen Widawsky
commit a0de80a0e07032a111230ec92eca563f9d93648d upstream. With updates to the spec, we can actually see the context layout, and how many dwords are allocated. That table suggests we need 70720 bytes per HW context. Rounded up, this is 18 pages. Looking at what lives after the current 4 pages we use, I can't see too much important (mostly it's d3d related), but there are a couple of things which look scary. I am hopeful this can explain some of our odd HSW failures. v2: Make the context only 17 pages. The power context space isn't used ever, and execlists aren't used in our driver, making the actual total 66944 bytes. v3: Add a comment to the code. (Jesse & Paulo) Reported-by: "Azad, Vinit" <vinit.azad@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-25drm/i915: Fix up sdvo hpd pins for i965g/gmDaniel Vetter
commit 4f7fd7095d85cd31c86cb9ba87bc301319630ccc upstream. Bspec seems to be full of lies, at least it disagress with reality: Two systems corrobated that SDVO hpd bits are the same as on gen3. v2: Update comment a bit. Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Arthur Ranyan <arthur.j.runyan@intel.com> Reported-and-tested-by: Alex Fiestas <afiestas@kde.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Acked-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-06-28drm/qxl: add missing access check for execbuffer ioctlDave Airlie
Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-25drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.Konrad Rzeszutek Wilk
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 ("drm/i915: create compact dma scatter lists for gem objects") makes certain assumptions about the under laying DMA API that are not always correct. On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup I see: [drm:intel_pipe_set_base] *ERROR* pin & fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Bit of debugging traced it down to dma_map_sg failing (in i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB). That unfortunately are sizes that the SWIOTLB is incapable of handling - the maximum it can handle is a an entry of 512KB of virtual contiguous memory for its bounce buffer. (See IO_TLB_SEGSIZE). Previous to the above mention git commit the SG entries were of 4KB, and the code introduced by above git commit squashed the CPU contiguous PFNs in one big virtual address provided to DMA API. This patch is a simple semi-revert - were we emulate the old behavior if we detect that SWIOTLB is online. If it is not online then we continue on with the new compact scatter gather mechanism. An alternative solution would be for the the '.get_pages' and the i915_gem_gtt_prepare_object to retry with smaller max gap of the amount of PFNs that can be combined together - but with this issue discovered during rc7 that might be too risky. Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: David Airlie <airlied@linux.ie> CC: <dri-devel@lists.freedesktop.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-06-25Merge tag 'drm-intel-fixes-2013-06-24' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes One remaining regression fix for i915. I've left it in -fixes for more than a week since it's in tricky code, and it took us a few kernel releases to notice the regression at all. The fence leak is especially annoying on gen2/3 and will kill userspace there quickly. For extra paranoia we've added a WARN in -next to catch this, things seem to be solid now. * tag 'drm-intel-fixes-2013-06-24' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Restore fences after resume and GPU resets
generated by cgit v1.2.3 (git 2.0.4) at 2025-01-07 20:00:38 +0000