- 15 1月, 2013 1 次提交
-
-
由 Chris Wilson 提交于
These are useful for investigating hangs involving WAIT_FOR_EVENT. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: Apply a droplet of Future-Proof in the if-ladder.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 1月, 2013 1 次提交
-
-
由 Daniel Vetter 提交于
This partially reverts commit 6c085a72 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 20 11:40:46 2012 +0200 drm/i915: Track unbound pages Closer inspection of that patch revealed a bunch of unrelated changes in the shrinker: - The shrinker count is now in pages instead of objects. - For counting the shrinkable objects the old code only looked at the inactive list, the new code looks at all bounds objects (including pinned ones). That is obviously in addition to the new unbound list. - The shrinker cound is no longer scaled with sysctl_vfs_cache_pressure. Note though that with the default tuning value of vfs_cache_pressue = 100 this doesn't affect the shrinker behaviour. - When actually shrinking objects, the old code first dropped purgeable objects, then normal (inactive) objects. Only then did it, in a last-ditch effort idle the gpu and evict everything. The new code omits the intermediate step of evicting normal inactive objects. Safe for the first change, which seems benign, and the shrinker count scaling, which is a bit a different story, the endresult of all these changes is that the shrinker is _much_ more likely to fall back to the last-ditch resort of idling the gpu and evicting everything. The old code could only do that if something else evicted lots of objects meanwhile (since without any other changes the nr_to_scan will be smaller than the object count). Reverting the vfs_cache_pressure behaviour itself is a bit bogus: Only dentry/inode object caches should scale their shrinker counts with vfs_cache_pressure. Originally I've had that change reverted, too. But Chris Wilson insisted that it's too bogus and shouldn't again see the light of day. Hence revert all these other changes and restore the old shrinker behaviour, with the minor adjustment that we now first scan the unbound list, then the inactive list for each object category (purgeable or normal). A similar patch has been tested by a few people affected by the gen4/5 hangs which started to appear in 3.7, which some people bisected to the "drm/i915: Track unbound pages" commit. But just disabling the unbound logic alone didn't change things at all. Note that this patch doesn't fix the referenced bugs, it only hides the underlying bug(s) well enough to restore pre-3.7 behaviour. The key to achieve that is to massively reduce the likelyhood of going into a full gpu stall and evicting everything. v2: Reword commit message a bit, taking Chris Wilson's comment into account. v3: On Chris Wilson's insistency, do not reinstate the rather bogus vfs_cache_pressure change. Tested-by: NGreg KH <gregkh@linuxfoundation.org> Tested-by: NDave Kleikamp <dave.kleikamp@oracle.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=55984 References: https://bugs.freedesktop.org/show_bug.cgi?id=57122 References: https://bugs.freedesktop.org/show_bug.cgi?id=56916 References: https://bugs.freedesktop.org/show_bug.cgi?id=57136 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 1月, 2013 2 次提交
-
-
由 Chris Wilson 提交于
This fixes an original bug in the sprite code that miscomputed the source offset into a linear YUV packed framebuffer, that was magnified into an oops with commit 5a35e99e Author: Damien Lespiau <damien.lespiau@intel.com> Date: Fri Oct 26 18:20:12 2012 +0100 drm/i915: adjust sprite base address Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
This proves to be very useful when investigating why code suddenly started failing. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 1月, 2013 3 次提交
-
-
由 Chris Wilson 提交于
This fixes a regression from commit 57779d06 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Oct 31 17:50:14 2012 +0200 drm/i915: Fix display pixel format handling (which even says that they are supported on Ironlake, and then promptly rejects then...) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Avoid clobbering adjacent blocks if they happen to expire earlier and amalgamate together to form the requested hole. In passing this fixes a regression from commit ea7b1dd4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Feb 18 17:59:12 2011 +0100 drm: mm: track free areas implicitly which swaps the end address for size (with a potential overflow) and effectively causes the eviction code to clobber almost all earlier buffers above the evictee. v2: Check the original hole not the adjusted as the coloring may confuse us when later searching for the overlapping nodes. Also make sure that we do apply the range restriction and color adjustment in the same order for both scanning, searching and insertion. v3: Send the version that was actually tested. Note that this seems to be ducttape of decent quality ot paper over some of our unbind related gpu hangs reported since 3.7. It is not fully effective though, and certainly doesn't fix the underlying bug. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Added note plus bugzilla link and tested-by.] Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984Tested-by: NNorbert Preining <preining@logic.at> Acked-by: Dave Airlie <airlied@gmail.com Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Prevent a divide-by-zero by consistently treating an 'active' CRTC without a mode set as actually disabled. This looks to have been first introduced with commit 24929352 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jul 2 20:28:59 2012 +0200 drm/i915: read out the modeset hw state at load and resume time but then combined with commit b0a2658a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Dec 18 09:37:54 2012 +0100 drm/i915: don't disable disconnected outputs it finally started oopsing. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: NAlexey Zaytsev <alexey.zaytsev@gmail.com> Tested-by: NSedat Dilek <sedat.dilek@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 1月, 2013 2 次提交
-
-
由 Daniel Vetter 提交于
This reverts commit 9756fe38. The bogus lvds output is actually a lvds->hdmi bridge, which we don't really support. But unconditionally disabling it breaks some existing setups. Reported-by: NJohn Tapsell <johnflux@gmail.com> References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
As along the error path we do not correct the user pin-count for the failure, we may end up with userspace believing that it has a pinned object at offset 0 (when interrupted by a signal for example). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 12月, 2012 7 次提交
-
-
由 Dave Airlie 提交于
This reverts commit 83c0bcb6. Lucas pointed out this was a mistake, and I missed the discussion, so just revert it out to save a rebase. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lucas Stach 提交于
The intention is to program exactly WIN_A, not WIN_A and possibly others. Signed-off-by: NLucas Stach <dev@lynxeye.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lucas Stach 提交于
There is no gem.c anymore, those functions are implemented by the drm_cma_helpers now. Signed-off-by: NLucas Stach <dev@lynxeye.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lucas Stach 提交于
The 720p and 1080p entries are completely redundant, as we are matching the table entries against <=pclk. Also generalize the comment, as we are using those table entries even when driving other modes than the standard TV ones. Signed-off-by: NLucas Stach <dev@lynxeye.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lucas Stach 提交于
Window properties are programmed through a shared aperture and have to happen atomically. Also we do the read-update-write dance on some of the shared regs. To make sure that different functions don't stumble over each other protect the register access with a mutex. Signed-off-by: NLucas Stach <dev@lynxeye.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lucas Stach 提交于
No real problem for now, as nothing is using this, but leaving it unitialized is asking for trouble later on. Signed-off-by: NLucas Stach <dev@lynxeye.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Lucas Stach 提交于
Fixes wrong picture offset observed when using HDMI output with a Technisat HD TV. Signed-off-by: NLucas Stach <dev@lynxeye.de> Acked-by: NMark Zhang <markz@nvidia.com> Tested-by: NMark Zhang <markz@nvidia.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 23 12月, 2012 8 次提交
-
-
由 Ben Skeggs 提交于
Also adds GK106 to chipsets known by ucode. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
This fixes suspend/resume on at least Quadro 400. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Modesetting seems to work alright, as does graphics (using binary driver fuc from nve7...). Lots to be done no doubt, but this'll get an image on the screen for people. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 22 12月, 2012 1 次提交
-
-
由 Alex Deucher 提交于
It's used in a recent mesa commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=24b1206ab2dcd506aaac3ef656aebc8bc20cd27a and there may be some other cases in the future where it's required. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org
-
- 20 12月, 2012 8 次提交
-
-
由 Daniel Vetter 提交于
The mmap offset structure is not part of the drm/i915 code, but provided by gem helpers. To avoid leaky abstractions (by either depending upon implementation details of said helper wrt to preallocations, or reimplementing it in our code and so fuzzing around in internal details of that helpr) simply disable the shrinker lock stealing accross calls into the helper functions. This should fix igt/gem_tiled_swapping. v2: Fix cleanup path confusion bemoaned by Chris Wilson. Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
commit 5774506f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 21 13:04:04 2012 +0000 drm/i915: Borrow our struct_mutex for the direct reclaim added a nice trick to steal the struct_mutex lock in the shrinker if it's the current task holding it. But this also caused the requirement that every place which allocates memory needs to be careful about the gem state of objects, since the shrinker could have pulled the rug out from under it. We've usually solved this by carefully preallocating things or ensure that buffers are pinned already. But the shrinker also reaps mmap offset, so allocating those needs to be careful, too. Now that code has been factored out into some common helpers, so either we have fragile code depending upon the common helper not doing something we don't want it to do. Or we need to reimplement the mmap offset creation and so also leak implementation details into our code. Since this all results in leaky abstraction, cop out by disabling the lock borrowing trick while calling down into the helpers. That way our craziness is nicely confined to files in drm/i915. v2: Split out the change to create_mmap_offset as request by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Dave Airlie 提交于
As pointed out by Seung-Woo Kim this should have been passing flags like nouveau/radeon have. Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jerome Glisse 提交于
To make it easier to debug some lockup from userspace add support to MEM_WRITE packet. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jerome Glisse 提交于
Modeset path seems to conflict sometimes with the memory management leading to kernel deadlock. This move modesetting reset after GPU acceleration reset. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Jerome Glisse 提交于
radeon_fence_wait_empty_locked should not trigger GPU reset as no place where it's call from would benefit from such thing and it actually lead to a kernel deadlock in case the reset is triggered from pm codepath. Instead force ring completion in place where it makes sense or return early in others. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Jerome Glisse 提交于
Force all fence to signal if GPU reset failed so no process get stuck on waiting fence. Signed-off-by: NJerome Glisse <jglisse@redhat.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Maarten Lankhorst 提交于
Fix regression introduced by 85b144f8 "drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3" Slowpath ttm_bo_cleanup_refs_and_unlock accidentally tried to increase refcount on &bo->sync_obj instead of bo->sync_obj. The compiler didn't complain since sync_obj_ref takes a void pointer, so it was still valid c. This could result in lockups, memory corruptions, and warnings like these when graphics card VRAM usage is high: ------------[ cut here ]------------ WARNING: at include/linux/kref.h:42 radeon_fence_ref+0x2c/0x40() Hardware name: System Product Name Pid: 157, comm: X Not tainted 3.7.0-rc7-00520-g85b144f8-dirty #174 Call Trace: [<ffffffff81058c84>] ? warn_slowpath_common+0x74/0xb0 [<ffffffff8129273c>] ? radeon_fence_ref+0x2c/0x40 [<ffffffff8125e95c>] ? ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0 [<ffffffff8125f17c>] ? ttm_mem_evict_first+0x1dc/0x2a0 [<ffffffff81264452>] ? ttm_bo_man_get_node+0x62/0xb0 [<ffffffff8125f4ce>] ? ttm_bo_mem_space+0x28e/0x340 [<ffffffff8125fb0c>] ? ttm_bo_move_buffer+0xfc/0x170 [<ffffffff810de172>] ? kmem_cache_alloc+0xb2/0xc0 [<ffffffff8125fc15>] ? ttm_bo_validate+0x95/0x110 [<ffffffff8125ff7c>] ? ttm_bo_init+0x2ec/0x3b0 [<ffffffff8129419a>] ? radeon_bo_create+0x18a/0x200 [<ffffffff81293e80>] ? radeon_bo_clear_va+0x40/0x40 [<ffffffff812a5342>] ? radeon_gem_object_create+0x92/0x160 [<ffffffff812a575c>] ? radeon_gem_create_ioctl+0x6c/0x150 [<ffffffff812a529f>] ? radeon_gem_object_free+0x2f/0x40 [<ffffffff81246b60>] ? drm_ioctl+0x420/0x4f0 [<ffffffff812a56f0>] ? radeon_gem_pwrite_ioctl+0x20/0x20 [<ffffffff810f53a4>] ? do_vfs_ioctl+0x2e4/0x4e0 [<ffffffff810e5588>] ? vfs_read+0x118/0x160 [<ffffffff810f55ec>] ? sys_ioctl+0x4c/0xa0 [<ffffffff810e5851>] ? sys_read+0x51/0xa0 [<ffffffff814b0612>] ? system_call_fastpath+0x16/0x1b Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de> Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 19 12月, 2012 4 次提交
-
-
由 Krzysztof Mazur 提交于
Some broken systems (like HP nc6120) in some cases, usually after LID close/open, enable VGA plane, making display unusable (black screen on LVDS, some strange mode on VGA output). We used to disable VGA plane only once at startup. Now we also check, if VGA plane is still disabled while changing mode, and fix that if something changed it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434Signed-off-by: NKrzysztof Mazur <krzysiek@podlesie.net> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
As we may reap neighbouring objects in order to free up pages for allocations, we need to be careful not to allocate in the middle of the drm_mm manager. To accomplish this, we can simply allocate the drm_mm_node up front and then use the combined search & insert drm_mm routines, reducing our code footprint in the process. Fixes (partially) i-g-t/gem_tiled_swapping Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJani Nikula <jani.nikula@intel.com> [danvet: Again fixup atomic bikeshed.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Required by i915 in order to avoid the allocation in the middle of manipulating the drm_mm lists. Use a pair of stubs to preserve the existing EXPORT_SYMBOLs for backporting; to be removed later. Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJani Nikula <jani.nikula@intel.com> [danvet: bikeshedded-away the atomic parameter, it's not yet used anywhere.] Acked-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
This piece of neat lore has been ported painstakingly and bug-for-bug compatible from the old crtc helper code. Imo it's utter nonsense. If you disconnected a cable and before you reconnect it, userspace (or the kernel) does an set_crtc call, this will result in that connector getting disabled. Which will result in a nice black screen when plugging in the cable again. There's absolutely no reason the kernel does such policy enforcements - if userspace tries to set up a mode on something disconnected we might fail loudly (since the dp link training fails), but silently adjusting the output configuration behind userspace's back is a recipe for disaster. Specifically I think that this could explain some of our MI_WAIT hangs around suspend, where userspace issues a scanline wait on a disable pipe. This mechanisims here could explain how that pipe got disabled without userspace noticing. Note that this fixes a NULL deref at BIOS takeover when the firmware sets up a disconnected output in a clone configuration with a connected output on the 2nd pipe: When doing the full modeset we don't have a mode for the 2nd pipe and OOPS. On the first pipe this doesn't matter, since at boot-up the fbdev helpers will set up the choosen configuration on that on first. Since this is now the umptenth bug around handling this imo brain-dead semantics correctly, I think it's time to kill it and see whether there's any userspace out there which relies on this. It also nicely demonstrates that we have a tiny window where DP hotplug can still kill the driver. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58396 Cc: stable@vger.kernel.org Tested-by: NPeter Ujfalusi <peter.ujfalusi@gmail.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 12月, 2012 2 次提交
-
-
由 Daniel Vetter 提交于
Now that Chris Wilson demonstrated that the key for stability on early gen 2 is to simple _never_ exchange the physical backing storage of batch buffers I've tried a stab at a kernel solution. Doesn't look too nefarious imho, now that I don't try to be too clever for my own good any more. v2: After discussing the various techniques, we've decided to always blit batches on the suspect devices, but allow userspace to opt out of the kernel workaround assume full responsibility for providing coherent batches. The principal reason is that avoiding the blit does improve performance in a few key microbenchmarks and also in cairo-trace replays. Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: - Drop the hunk which uses HAS_BROKEN_CS_TLB to implement the ring wrap w/a. Suggested by Chris Wilson. - Also add the ACTHD check from Chris Wilson for the error state dumping, so that we still catch batches when userspace opts out of the w/a.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
I'm not really sure, since the w/a entry is as thin on details as ever, and Bspec doesn't say anything about it. But I've figured only dispatching to rows 0&1 instead of all four should be the right thing for GT1. Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add the missing snb server GT1 to the check, spotted by Chris Wilson.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 12月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
Quoting from Bspec, 3D_CHICKEN1, bit 10 This bit needs to be set always to "1", Project: DevSNB " Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-