summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_gem.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Improve behaviour under memory pressureChris Wilson2009-09-171-81/+232
| | | | | | | | | | | | | | | | | | | Due to the necessity of having to take the struct_mutex, the i915 shrinker can not free the inactive lists if we fail to allocate memory whilst processing a batch buffer, triggering an OOM and an ENOMEM that is reported back to userspace. In order to fare better under such circumstances we need to manually retry a failed allocation after evicting inactive buffers. To do so involves 3 steps: 1. Marking the backing shm pages as NORETRY. 2. Updating the get_pages() callers to evict something on failure and then retry. 3. Revamping the evict something logic to be smarter about the required buffer size and prefer to use volatile or clean inactive pages. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Add ioctl to set 'purgeability' of objectsChris Wilson2009-09-171-8/+73
| | | | | | | | | | Similar to the madvise() concept, the application may wish to mark some data as volatile. That is in the event of memory pressure the kernel is free to discard such buffers safe in the knowledge that the application can recreate them on demand, and is simply using these as a cache. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Register a shrinker to free inactive lists under memory pressureChris Wilson2009-09-171-0/+144
| | | | | | | This should help GEM handle memory pressure sitatuions more gracefully. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Remove stored gtt_alignmentChris Wilson2009-09-171-12/+2
| | | | | | | | | There is no need to store the gtt_alignment as it is either explicitly set according to the hardware requirements (e.g. scanout) or the minimum alignment is computed on demand. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Add buffer to inactive list immediately during faultChris Wilson2009-09-171-2/+1
| | | | | | | | | If we failed to set the domain, the buffer was no longer being tracked on any list. Cc: stable@kernel.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Make dev_priv->mm.wedged an atomic_tBen Gamari2009-09-171-9/+9
| | | | | | | | | There is a very real possibility that multiple CPUs will notice that the GPU is wedged. This introduces all sorts of potential race conditions. Make the wedged flag atomic to mitigate this risk. Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Add hangcheck timerBen Gamari2009-09-171-2/+6
| | | | | | | | | | | | | | | | | | | | | | | We set a periodic timer to check on the GPU, resetting it every time a batch is completed. If the timer elapses, we check acthd. If acthd hasn't changed in two timer periods, we assume the chip is wedged. This is implemented in such a way that it leaves the option open to employ adaptive timer intervals in the future. One could wait until several timer periods have elapsed before declaring the chip dead. If the chip comes back after several periods but before the "dead" threshold, the timer interval or dead threshold could be raised. It is important to note that while checking for active requests, we need to account for the fact that requests are removed from the list (i.e. retired) in a deferred work queue handler. This means that merely checking for an empty request_list is insufficient; the list could be non-empty yet the GPU still idle, causing the hangcheck timer to incorrectly mark the GPU as wedged (it took me a while to figure that out---sigh...) Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: make i915_seqno_passed non-staticBen Gamari2009-09-171-1/+1
| | | | | | | | We'll need it in i915_irq.c for checking whether there are outstanding requests. Also, the function really ought to return a bool, not an int. Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Check whether chip is wedged in i915_wait_request()Ben Gamari2009-09-171-0/+3
| | | | | | | | | | i915_wait_request() only checks mm.wedged after it interacts with the hardware, generally causing the driver to lock up waiting for a wedged chip. Make sure we check mm.wedged as the first thing we do. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Only destroy a constructed mmap offsetChris Wilson2009-09-111-1/+2
| | | | | | | | | | | | | | | | | | drm_ht_remove_item() does not handle removing an absent item and the hlist in particular is incorrectly initialised. The easy remedy is simply skip calling i915_gem_free_mmap_offset() unless we have actually created the offset and associated ht entry. This also fixes the mishandling of a partially constructed offset which leaves pointers initialized after freeing them along the i915_gem_create_mmap_offset() error paths. In particular this should fix the oops found here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/415357/comments/8 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Cc: stable@kernel.org
* agp/intel: Fix the pre-9xx chipset flush.Eric Anholt2009-09-111-10/+0
| | | | | | | | | | | | | | | | | | | | | | | Ever since we enabled GEM, the pre-9xx chipsets (particularly 865) have had serious stability issues. Back in May a wbinvd was added to the DRM to work around much of the problem. Some failure remained -- easily visible by dragging a window around on an X -retro desktop, or by looking at bugzilla. The chipset flush was on the right track -- hitting the right amount of memory, and it appears to be the only way to flush on these chipsets, but the flush page was mapped uncached. As a result, the writes trying to clear the writeback cache ended up bypassing the cache, and not flushing anything! The wbinvd would flush out other writeback data and often cause the data we wanted to get flushed, but not always. By removing the setting of the page to UC and instead just clflushing the data we write to try to flush it, we get the desired behavior with no wbinvd. This exports clflush_cache_range(), which was laying around and happened to basically match the code I was otherwise going to copy from the DRM. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Brice Goglin <Brice.Goglin@ens-lyon.org> Cc: stable@kernel.org
* drm/i915: Zap mmaps of objects before unbinding them from the GTT.Eric Anholt2009-09-091-8/+8
| | | | | | | | | Otherwise, some other userland writing into its buffer may race to land writes either after the CPU thinks it's got a coherent view, or after its GTT entries have been redirected to point at the scratch page. Either result is unpleasant. Signed-off-by: Eric Anholt <eric@anholt.net>
* Merge intel drm-intel-next branchDave Airlie2009-09-071-40/+60
|\ | | | | | | | | | | | | | | | | Merge remote branch 'anholt/drm-intel-next' of ../anholt-2.6 into drm-next Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h drivers/gpu/drm/i915/intel_sdvo.c
| * drm/i915: Pad ringbuffer with NOOPs before wrappingChris Wilson2009-09-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the docs, the ringbuffer is not allowed to wrap in the middle of an instruction. G45 PRM, Vol 1b, p101: While the “free space” wrap may allow commands to be wrapped around the end of the Ring Buffer, the wrap should only occur between commands. Padding (with NOP) may be required to follow this restriction. Do as commanded. [Having seen bug reports where there is evidence of split commands, but apparently the GPU has continued on merrily before a bizarre and untimely death, this may or may not fix a few random hangs.] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Eric Anholt <eric@anholt.net> Signed-off-by: Eric Anholt <eric@anholt.net>
| * drm/i915: add dynamic clock frequency controlJesse Barnes2009-09-041-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several sources of unnecessary power consumption on Intel graphics systems. The first is the LVDS clock. TFTs don't suffer from persistence issues like CRTs, and so we can reduce the LVDS refresh rate when the screen is idle. It will be automatically upclocked when userspace triggers graphical activity. Beyond that, we can enable memory self refresh. This allows the memory to go into a lower power state when the graphics are idle. Finally, we can drop some clocks on the gpu itself. All of these things can be reenabled between frames when GPU activity is triggered, and so there should be no user visible graphical changes. Signed-off-by: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
| * drm/i915: Unref old_obj on get_fence_reg() error pathChris Wilson2009-09-021-4/+9
| | | | | | | | | | | | | | | | | | | | | | Remember to release the local reference if we fail to wait on the rendering. (Also whilst in the vicinity add some whitespace so that the phasing of the operations is clearer.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
| * drm/i915: Fix CPU-spinning hangs related to fence usage by using an LRU.Eric Anholt2009-08-291-38/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The lack of a proper LRU was partially worked around by taking the fence from the object containing the oldest seqno. But if there are multiple objects inactive, then they don't have seqnos and the first fence reg among them would be chosen. If you were trying to copy data between two mappings, this could result in each page fault stealing the fence from the other argument, and your application hanging. https://bugs.freedesktop.org/show_bug.cgi?id=23566 https://bugs.freedesktop.org/show_bug.cgi?id=23220 https://bugs.freedesktop.org/show_bug.cgi?id=23253 https://bugs.freedesktop.org/show_bug.cgi?id=23366 Cc: Stable Team <stable@kernel.org> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm: GEM handles are u32, not intPekka Paalanen2009-08-271-1/+2
|/ | | | | | | | | | Several functions in the GEM kernel API used int as handle type, but user API has it __u32 which is also the intended type. Replace int with u32. Signed-off-by: Pekka Paalanen <pq@iki.fi> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Use our own workqueue to avoid wedging the system along with the GPU.Eric Anholt2009-08-051-2/+2
| | | | Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Zap the GTT mapping when transitioning from untiled to tiled.Eric Anholt2009-07-101-1/+1
| | | | | | | | As of 52dc7d32b88156248167864f77a9026abe27b432, we could leave an old linear GTT mapping in place, so that apps trying to GTT-mapped write in tiled data wouldn't get the fence added, and garbage would get displayed. Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Refactor calls to unmap_mapping_rangeChris Wilson2009-07-101-9/+27
| | | | | | | | As we call unmap_mapping_range() twice in identical fashion, refactor and attempt to explain why we need to call unmap_mapping_range(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: initialize fence registers to zero when loading GEMGrégoire Henry2009-06-231-0/+13
| | | | | | | | | | | Unitialized fence register could leads to corrupted display. Problem encountered on MacBooks (revision 1 and 2), directly booting from EFI or through BIOS emulation. (bug #21710 at freedestop.org) Signed-off-by: Grégoire Henry <henry@pps.jussieu.fr> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Fix size_t handling in off-by-default debug printfsKrzysztof Halasa2009-06-221-3/+3
| | | | | Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm: Remove memory debugging infrastructure.Eric Anholt2009-06-181-19/+16
| | | | | | | | It hasn't been used in ages, and having the user tell your how much memory is being freed at free time is a recipe for disaster even if it was ever used. Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Clear fence register on tiling stride change.Chris Wilson2009-06-181-1/+36
| | | | | | | | | | The fence register value also depends upon the stride of the object, so we need to clear the fence if that is changed as well. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [anholt: Added 8xx and 965 paths, and renamed the confusing i915_gem_object_tiling_ok function to i915_gem_object_fence_offset_ok] Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Install fence register for tiled scanout on i915Chris Wilson2009-06-181-6/+4
| | | | | | | | | | | | With the work by Jesse Barnes to eliminate allocation of fences during execbuffer, it becomes possible to write to the scan-out buffer with it never acquiring a fence (simply by only ever writing to the object using tiled GPU commands and never writing to it via the GTT). So for pre-i965 chipsets which require fenced access for tiled scan-out buffers, we need to obtain a fence register. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: detach/attach get/put pages symmetryChris Wilson2009-06-171-0/+4
| | | | | | | | | | | After performing an operation over the page list for a buffer retrieved by i915_gem_object_get_pages() the pages need to be returned with i915_gem_object_put_pages(). This was not being observed for the phys objects which were thus leaking references to their backing pages. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Dave Airlie <airlied@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: NOMEM->NOSPCChris Wilson2009-06-091-5/+5
| | | | | | | | To differentiate between encountering an out-of-memory error with running out of space in the aperture, use ENOSPC for the later. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: use I915_GEM_GPU_DOMAINSChris Wilson2009-06-091-13/+9
| | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: no need to hold mutex for object lookupChris Wilson2009-06-091-2/+1
| | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: OR in the COMMAND read domain for the batch buffer.Chris Wilson2009-06-091-2/+6
| | | | | | | | | The batch buffer may be shared with another read buffer, so we should not ignore any previously set domains, but just or in the command domain (and check that the buffer is not writable). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Sanity check execbuffer arguments before touching state.Chris Wilson2009-06-091-11/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By sending a broken execbuffer (its length was not suitably aligned) I triggered an operation upon a freed object. The invalid alignment was discovered after updating the write_domain on the object but before the object was placed on the active queue. So during the unwind process following the error, the now freed object attempts to flush its non-existent, but outstanding, GPU writes causing this use-after-free. [drm:i915_dispatch_gem_execbuffer] *ERROR* alignment [drm:i915_gem_execbuffer] *ERROR* dispatch failed -22 WARNING: at lib/kref.c:43 warn_slowpath_null+0x10/0x15() Modules linked in: Pid: 4552, comm: lt-csi-drm Not tainted 2.6.30-rc6 #423 Call Trace: [<c0119ef3>] warn_slowpath_fmt+0x57/0x6d [<c014de24>] ? get_pageblock_migratetype+0x18/0x1e [<c014e8fd>] ? free_hot_page+0xa/0xc [<c014e915>] ? __free_pages+0x16/0x1f [<c0153ebf>] ? shmem_truncate_range+0x63e/0x656 [<c015fb2f>] ? slob_page_alloc+0x146/0x1c8 [<c0119f19>] warn_slowpath_null+0x10/0x15 [<c01f55f2>] kref_get+0x1b/0x21 [<c02605db>] i915_gem_object_move_to_active+0x1f/0x56 [<c0261302>] i915_add_request+0x156/0x19a [<c026136e>] i915_gem_object_flush_gpu_write_domain+0x28/0x3f [<c0261eca>] i915_gem_object_unbind+0x4a/0x124 [<c0261fd7>] i915_gem_free_object+0x33/0x9b [<c0250d6b>] drm_gem_object_free+0x28/0x4a [<c0250d43>] ? drm_gem_object_free+0x0/0x4a [<c01f55ce>] kref_put+0x38/0x41 [<c0250cbf>] drm_gem_object_unreference+0x11/0x13 [<c0250d06>] drm_gem_object_handle_unreference+0x1e/0x21 [<c0250d13>] drm_gem_object_release_handle+0xa/0xe [<c01f3e6b>] idr_for_each+0x5f/0x98 [<c0250d09>] ? drm_gem_object_release_handle+0x0/0xe [<c0250daf>] drm_gem_release+0x22/0x34 [<c025046f>] drm_release+0x1e8/0x3c4 [<c0162d25>] __fput+0xaf/0x146 [<c0162dce>] fput+0x12/0x14 [<c01605ef>] filp_close+0x48/0x52 [<c011b182>] put_files_struct+0x57/0x9b [<c011b1e4>] exit_files+0x1e/0x20 [<c011c6b6>] do_exit+0x16d/0x511 [<c03704ab>] ? __schedule+0x3d4/0x3e5 [<c0103f0d>] ? handle_irq+0xd/0x69 [<c011caa7>] do_group_exit+0x4d/0x73 [<c011cae0>] sys_exit_group+0x13/0x17 [<c010268c>] sysenter_do_call+0x12/0x2b Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: handle interrupt on new chipsetZhenyu Wang2009-06-091-1/+4
| | | | | | | | | | Update interrupt handling methods for IGDNG with new registers for display and graphics interrupt functions. As we won't use irq-based vblank sync in dri2, so display interrupt on new chip will be used for hotplug only in future. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Change GEM throttling to be 20ms like the comment says.Eric Anholt2009-06-041-15/+54
| | | | | | | | | | | | | | | | | | | keithp didn't like the original 20ms plan because a cooperative client could be starved by an uncooperative client. There may even have been problems with cooperative clients versus cooperative clients. So keithp changed throttle to just wait for the second to last seqno emitted by that client. It worked well, until we started getting more round-trips to the server due to DRI2 -- the server throttles in BlockHandler, and so if you did more than one round trip after finishing your frame, you'd end up unintentionally syncing to the swap. Fix this by keeping track of the client's requests, so the client can wait when it has an outstanding request over 20ms old. This should have non-starving behavior, good behavior in the presence of restarts, and less waiting. Improves high-settings openarena performance on my GM45 by 50%. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* drm/i915: Remove a bad BUG_ON in the fence management code.Eric Anholt2009-06-041-3/+0
| | | | | | | | | | This could be triggered by a gtt mapping fault on 965 that decides to remove the fence from another object that happens to be active currently. Since the other object doesn't rely on the fence reg for its execution, we don't wait for it to finish. We'll soon be not waiting on 915 most of the time as well, so just drop the BUG_ON. Signed-off-by: Eric Anholt <eric@anholt.net>
* i915: Set object to gtt domain when faulting it back inKristian Høgsberg2009-05-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | When a GEM object is evicted from the GTT we set it to the CPU domain, as it might get swapped in and out or ever mmapped regularly. If the object is mmapped through the GTT it can still get evicted in this way by other objects requiring GTT space. When the GTT mapping is touched again we fault it back into the GTT, but fail to set it back to the GTT domain. This means we fail to flush any cached CPU writes to the pages backing the object which will then happen "eventually", typically after we write to the page through the uncached GTT mapping. [anholt: Note that userland does do a set_domain(GTT, GTT) when starting to access the GTT mapping. That covers getting the existing mapping of the object synchronized if it's bound to the GTT. But set_domain(GTT, GTT) doesn't do anything if the object is currently unbound. This fix covers the transition to being bound for GTT mapping.] Fixes glyph and other pixmap corruption during swapping. fd.o bug #21790 Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Apply a big hammer to 865 GEM object CPU cache flushing.Eric Anholt2009-05-261-0/+10
| | | | | | | | | | | | | | On the 865, but not the 855, the clflush we do appears to not actually make it out to the hardware all the time. An easy way to safely reproduce was X -retro, which would show that some of the blits involved in drawing the lovely root weave didn't make it out to the hardware. Those blits are 32 bytes each, and 1-2 would be missing at various points around the screen. Other experimentation (doing more clflush, doing more AGP chipset flush, poking at some more device registers to maybe trigger more flushing) didn't help. krh came up with the wbinvd as a way to successfully get all those blits to appear. Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Fix tiling pitch handling on 8xx.Eric Anholt2009-05-261-2/+4
| | | | | | | | | | | | | The pitch field is an exponent on pre-965, so we were rejecting buffers on 8xx that we shouldn't have. 915 got lucky in that the largest legal value happened to match (8KB / 512 = 0x10), but 8xx has a smaller tile width. Additionally, we programmed that bad value into the register on 8xx, so the only pitch that would work correctly was 4096 (512-1023 pixels), while others would probably give bad rendering or hangs. Signed-off-by: Eric Anholt <eric@anholt.net> fd.o bug #20473.
* i915: support 8xx desktop cursorsJesse Barnes2009-05-221-2/+2
| | | | | | | | | | For some reason we never added 8xx desktop cursor support to the kernel. This patch fixes that. [krh: Also set the size on pre-i915 hw.] Tested-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: allocate large pointer arrays with vmallocJesse Barnes2009-05-191-23/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For awhile now, many of the GEM code paths have allocated page or object arrays with the slab allocator. This is nice and fast, but won't work well if memory is fragmented, since the slab allocator works with physically contiguous memory (i.e. order > 2 allocations are likely to fail fairly early after booting and doing some work). This patch works around the issue by falling back to vmalloc for >PAGE_SIZE allocations. This is ugly, but much less work than chaining a bunch of pages together by hand (suprisingly there's not a bunch of generic kernel helpers for this yet afaik). vmalloc space is somewhat precious on 32 bit kernels, but our allocations shouldn't be big enough to cause problems, though they're routinely more than a page. Note that this patch doesn't address the unchecked alloc-based-on-ioctl-args in GEM; that needs to be fixed in a separate patch. Also, I've deliberately ignored the DRM's "area" junk. I don't think anyone actually uses it anymore and I'm hoping it gets ripped out soon. [Updated: removed size arg to new free function. We could unify the free functions as well once the DRM mem tracking is ripped out.] fd.o bug #20152 (part 1/3) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: sanity check IER at wait_request timeJesse Barnes2009-05-141-0/+9
| | | | | | | | | | | | | | | | | | | | | | | We might sleep here anyway so I hope an extra uncached read is ok to add. In #20896 we found that vbetool clobbers the IER. In KMS mode this is particularly bad since we don't set the interrupt regs late (in EnterVT), so we'd fail to get *any* interrupts at all after X started (since some distros have scripts that call vbetool at X startup apparently). So this patch checks IER at wait_request time, and re-enables interrupts if it's been clobbered. In a proper config this check should never be triggered. This is really a distro issue, but having a sanity check is nice, as long as it doesn't have a real performance hit. Tested-by: Mateusz Kaduk <mateusz.kaduk@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: Moved the check inside of the sleeping case to avoid perf cost] Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: fix unpaired i915 device mutex on entervt failure.Wu Fengguang2009-04-211-1/+3
| | | | | Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: fix scheduling while holding the new active list spinlockShaohua Li2009-04-141-1/+12
| | | | | | | | | | regression caused by commit 5e118f4139feafe97e913df67b1f7c1e5083e535: i915_gem_object_move_to_inactive() should be called in task context, as it calls fput(); Signed-off-by: Shaohua Li<shaohua.li@intel.com> [anholt: Add more detail to the comment about the lock break that's added] Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.Eric Anholt2009-04-081-12/+118
| | | | | | | | | | | | Save the bit 17 state of the pages when freeing the page list, and reswizzle them if necessary when rebinding the pages (in case they were swapped out). Since we have userland with expectations that the swizzle enums let it pread and pwrite contents accurately, we can't expose a new swizzle enum for bit 17 (which it would have to GTT map to handle), so we handle it down in pread and pwrite by swizzling the copy when bit 17 of the page address is set. Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Correctly set the write flag for get_user_pages in pread.Eric Anholt2009-04-081-1/+1
| | | | | | | | Otherwise, the results of our read didn't show up when we were faulting in the page being read into (as happened with a testcase reading into a big stack area). Likely accounts for some conformance test failures. Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Fix use of uninitialized var in 40a5f0deFlorian Mickler2009-04-081-12/+22
| | | | | | | | | | | | | | | | i915_gem_put_relocs_to_user returned an uninitialized value which got returned to userspace. This caused libdrm in my setup to never get out of a do{}while() loop retrying i915_gem_execbuffer. result was hanging X, overheating of cpu and 2-3gb of logfile-spam. This patch adresses the issue by 1. initializing vars in this file where necessary 2. correcting wrongly interpreted return values of copy_[from/to]_user Signed-off-by: Florian Mickler <florian@mickler.org> [anholt: cleanups of unnecessary changes, consistency in APIs] Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Implement batch and ring buffer dumpingBen Gamari2009-04-081-5/+3
| | | | | | | | | | | | | | | | | | We create a debugfs node (i915_ringbuffer_data) to expose a hex dump of the ring buffer itself. We also expose another debugfs node (i915_ringbuffer_info) with information on the state (i.e. head, tail addresses) of the ringbuffer. For batchbuffer dumping, we look at the device's active_list, dumping each object which has I915_GEM_DOMAIN_COMMAND in its read domains. This is all exposed through the dri/i915_batchbuffers debugfs file with a header for each object (giving the objects gtt_offset so that it can be matched against the offset given in the BATCH_BUFFER_START command. Signed-off-by: Ben Gamari <bgamari@gmail.com> Signed-off-by: Carl Worth <cworth@cworth.org> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: Add a spinlock to protect the active_listCarl Worth2009-04-011-4/+20
| | | | | | | | | | | | This is a baby-step in the direction of having finer-grained locking than the struct_mutex. Specifically, this will enable new debugging code to read the active list for printing out GPU state when the GPU is wedged, (while the struct_mutex is held, of course). Signed-off-by: Carl Worth <cworth@cworth.org> [anholt: indentation fix] Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: check for -EINVAL from vm_insert_pfnJesse Barnes2009-04-011-0/+1
| | | | | | | | Indicates something is wrong with the mapping; and apparently triggers in current kernels. Signed-off-by: Jesse Barnes <jbarnes@virtuosugeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
* drm/i915: fix up tiling/fence reg setup on i8xx class hwDaniel Vetter2009-04-011-5/+8
| | | | | | | | | | | | | | | | | | | This fixes all the tiling problems with the 2d ddx. glxgears still doesn't work. Changes: - fix a copy&paste error in i8xx fence reg setup. It resulted in an at most a 512KB offset of the fence reg window, so was only visible sometimes. - add tests for stride and object size constrains (also for i915 and 1965 class hw). Userspace seems to have an of-by-one bug there, which changes the fence size by at most 512KB due to an overflow. - because i8xx hw is quite old (and therefore not as well-tested) I left 2 debug WARN_ONs in the i8xx fence reg setup code to hopefully catch any further overflows in the bit-fields. Lastly there's one small change to make the alignment checks more consistent. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=20289 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
OpenPOWER on IntegriCloud