- 29 Oct, 2010 12 commits
-
-
Chris Wilson authored
Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
My Sandybridge only reports 0 for the ring buffer registers, causing it to hang as soon as we exhaust the available ring. As a workaround, take advantage of our huge ring buffers and use the auto-reporting mechanism to update the status page with the HEAD location every 64 KiB. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
After switching the MMIO registers to use pci_iomap, remember to dispose of the mapping with pci_iounmap (for symmetry). Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
It should be idle on cleanup anyway... Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
So long as we adhere to the fence registers rules for alignment and no overlaps (including with unfenced accesses to linear memory) and account for the tiled access in our size allocation, we do not have to allocate the full fenced region for the object. This allows us to fight the bloat tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside the GTT we still suffer the additional alignment constraints, so it doesn't magic allow us to render larger scenes without stalls -- we need the expanded GTT and fence pipelining to overcome those...] Signed-off-by: -
Chris Wilson authored
Also spotted by Dan Carpenter. obj->pin_count is unsigned so the BUG_ON(obj->pin_count<0) will never trigger. Signed-off-by:
-
- 28 Oct, 2010 7 commits
-
-
Chris Wilson authored
The error code is only expected during the actual pruning and not during the first measurement (nr_to_scan == 0) pass. Signed-off-by: -
Chris Wilson authored
In order to force a page-fault on a GTT mapping after we start using it from the GPU and so enforce correct CPU/GPU synchronisation, we need to invalidate the mapping. Pointed out by Owain G. Ainsworth. Signed-off-by: -
Chris Wilson authored
By using read_cache_page() for individual pages during pwrite/pread we can eliminate an unnecessary large allocation (and immediate free) of obj->pages. Also this eliminates any potential nesting of get/put pages, simplifying the code and preparing the path for greater things. Signed-off-by: -
Chris Wilson authored
Since we rarely use the mmap_offset and it is easily computable from the obj->map_list.hash, remove it. Signed-off-by: -
Chris Wilson authored
Eliminate the racy device unload by embedding a shrinker into each device. Smaller, simpler code. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Play safe and use the common routines which take care of the cachability of the memory when setting up the iomapping for the PCI registers. Whilst they should be cacheable for the current generations, actually honouring what the device requires is a better long term strategy. Signed-off-by:
-
- 27 Oct, 2010 21 commits
-
-
Chris Wilson authored
This holds error state from the main graphics arbiter mainly involving the DMA engine and address translation. Signed-off-by: -
Chris Wilson authored
This is the same value as before, but it just makes the code slightly more readable to use the local variable than converting the aperture size into bytes every time. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Daniel Vetter authored
More precisely: For those that _need_ to be mappable. Also add two BUG_ONs in fault and pin to check the consistency of the mappable flag. Changes in v2: - Add tracking of gtt mappable space (to notice mappable/unmappable balancing issues). - Improve the mappable working set tracking by tracking fault and pin separately. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
This way we can make some more educated guesses as to why exactly we can't use 2G apertures to their full potential ;) Signed-off-by:
-
Daniel Vetter authored
On VT-d supporting platforms the GGTT is allocated in a stolen mem section separate from graphcis stolen mem. The GMCH register contains a bitfield specifying the size of that region. Docs suggest that this region can only be used for GGTT and PPGTT. Hence ensure that the PPGTT is disabled and use the complete area for the GGTT. Unfortunately the graphics core on G33/Pineview can't cope with really large GTTs and the BIOS usually enables the maximum of 512MB. So don't bother with maximizing the GTT on these platforms. Signed-off-by:
-
Daniel Vetter authored
... and switch to a more classical store-reg-on-suspend, restore-on-resume way of doing things. Obviously this is just preparation for the future, the code is not there at all, yet. This is needed because the next patch adjusts this register and everything in it (not just the pagetable address) needs to be restored on resume. Signed-off-by:
-
Daniel Vetter authored
At least the part that's currently enabled by the BIOS. Signed-off-by:
-
Daniel Vetter authored
In i915_gem_object_pin obviously unbind only if mappable is true. This is the last part to enable gtt_mappable_end != gtt_size, which the next patch will do. v2: Fences on g33/pineview only work in the mappable part of the gtt. Signed-off-by:
-
Daniel Vetter authored
Like before add a parameter mappable (also to gem_object_pin) and set it depending upon the context. Only bos that are brought into the gtt due to an execbuffer call can be put into the unmappable part of the gtt, everything else (especially pinned objects) need to be put into the mappable part of the gtt. Signed-off-by:
-
Daniel Vetter authored
Add a mappable parameter to i915_gem_evict_something to distinguish the two cases (non-restricted vs. mappable gtt allocations). No functional changes because the mappable limit is set to the end of the gtt currently. Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
The render ring is not alone any more! And the other rings are just as troublesome... Signed-off-by: -
Chris Wilson authored
Currently, we believe the GPU is idle if just the RENDER ring is idle. This is obviously wrong if we only using either the BLT or the BSD rings and so masking genuine hangs. Signed-off-by: -
Chris Wilson authored
In the event that we fail to dispatch the execbuffer, for example if there is insufficient space on the ring, we were leaving the objects in an inconsistent state. Notably they were marked as being in the GPU write domain, but were not added to the ring or any list. This would lead to inevitable oops: [ 1010.522940] [drm:i915_gem_do_execbuffer] *ERROR* dispatch failed -16 [ 1010.523055] BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 [ 1010.523097] IP: [<ffffffff8122d006>] i915_gem_flush_ring+0x26/0x140 [ 1010.523120] PGD 14cf2f067 PUD 14ce04067 PMD 0 [ 1010.523140] Oops: 0000 [#1] SMP [ 1010.523154] last sysfs file: /sys/devices/virtual/vc/vcsa2/uevent [ 1010.523173] CPU 0 [ 1010.523183] Pid: 716, comm: X Not tainted 2.6.36+ #34 LosLunas CRB/SandyBridge Platform [ 1010.523206] RIP: 0010:[<ffffffff8122d006>] [<ffffffff8122d006>] i915_gem_flush_ring+0x26/0x140 [ 1010.523233] RSP: 0018:ffff88014bf97cd8 EFLAGS: 00010296 [ 1010.523249] RAX: ffff88014e2d1808 RBX: 0000000000000000 RCX: 0000000000000000 [ 1010.523270] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 [ 1010.523290] RBP: ffff88014e2d1000 R08: 0000000000000002 R09: 00000000400c645f [ 1010.523311] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000002 [ 1010.523331] R13: ffff88014e29a000 R14: 00000000000000c8 R15: ffffffff8162eb28 [ 1010.523352] FS: 00007fc62379d700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 [ 1010.523375] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.523392] CR2: 0000000000000088 CR3: 000000014bf87000 CR4: 00000000000406f0 [ 1010.523412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1010.523433] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1010.523454] Process X (pid: 716, threadinfo ffff88014bf96000, task ffff88014cc1ee40) [ 1010.523475] Stack: [ 1010.523483] ffff88014d5199c0 0000000000000200 0000000000000000 ffff88014bcc6400 [ 1010.523509] <0> 0000000000000000 0000000000000001 ffff88014e29a000 ffff88014bcc6400 [ 1010.523537] <0> ffffffff8162eb28 ffffffff8122faa8 ffff88014e29a000 ffff88014bcc6400 [ 1010.523568] Call Trace: [ 1010.523578] [<ffffffff8122faa8>] ? i915_gem_object_flush_gpu_write_domain+0x48/0x80 [ 1010.523601] [<ffffffff8122fb8e>] ? i915_gem_object_set_to_gtt_domain+0x2e/0xb0 [ 1010.523623] [<ffffffff8123113b>] ? i915_gem_set_domain_ioctl+0xdb/0x1f0 [ 1010.523644] [<ffffffff8120a3f1>] ? drm_ioctl+0x3d1/0x460 [ 1010.523660] [<ffffffff81231060>] ? i915_gem_set_domain_ioctl+0x0/0x1f0 [ 1010.523682] [<ffffffff81092618>] ? vma_prio_tree_insert+0x28/0x120 [ 1010.523701] [<ffffffff8109f379>] ? vma_link+0x99/0xf0 [ 1010.523717] [<ffffffff810a111d>] ? mmap_region+0x1ed/0x4f0 [ 1010.523734] [<ffffffff810c306f>] ? do_vfs_ioctl+0x9f/0x580 [ 1010.523750] [<ffffffff810c3599>] ? sys_ioctl+0x49/0x80 [ 1010.523767] [<ffffffff810022eb>] ? system_call_fastpath+0x16/0x1b [ 1010.523785] Code: 00 00 00 00 00 41 57 89 ce 41 56 41 55 41 54 45 89 c4 55 48 89 fd 53 48 89 d3 44 89 c2 48 89 df 4c 8d b3 c8 00 00 00 48 83 ec 18 <ff> 93 88 00 00 00 48 8b 83 c8 00 00 00 4c 8b bd 30 03 00 00 48 [ 1010.523946] RIP [<ffffffff8122d006>] i915_gem_flush_ring+0x26/0x140 [ 1010.523966] RSP <ffff88014bf97cd8> [ 1010.523977] CR2: 0000000000000088 Signed-off-by: -
Chris Wilson authored
Preparing the ringbuffer for adding new commands can fail (a timeout whilst waiting for the GPU to catch up and free some space). So check for any potential error before overwriting HEAD with new commands, and propagate that error back to the user where possible. Signed-off-by: -
Chris Wilson authored
The ringbuffer keeps a pointer to the parent device, so we can use that instead of passing around the pointer on the stack. Signed-off-by: -
Takashi Iwai authored
Hi, while I looked through your changes in drm-intel git tree (as I've got a pressure for supporting DisplayPort audio), I stumbled on the possible bug in the commit a9756bb5 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Sun Sep 19 13:09:06 2010 +0800 drm/i915: Enable DisplayPort audio In this commit, you changed the return value of g4x_dp_detect() to "bit", but it should be "status", I suppose. [ickle: mea culpa.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31094Signed-off-by:
-
Al Viro authored
usbfs_get_inode() is something completely different... Bogosity introduced by commit 85fe4025 ("fs: do not assign default i_ino in new_inode"). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
