summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2010-11-02Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson
Immediate merge to resolve conflicts from applying a stability fix to both branches. Conflicts: drivers/gpu/drm/i915/intel_ringbuffer.c drivers/gpu/drm/i915/intel_ringbuffer.h
2010-11-02drm/i915: SNB BLT workaroundChris Wilson
On some stepping of SNB cpu, the first command to be parsed in BLT command streamer should be MI_BATCHBUFFER_START otherwise the GPU may hang. (cherry picked from commit 8d19215be8254f4f75e9c5a0d28345947b0382db) Conflicts: drivers/gpu/drm/i915/intel_ringbuffer.c drivers/gpu/drm/i915/intel_ringbuffer.h Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Cc: stable@kernel.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-02drm/i915: SNB BLT workaroundZou Nan hai
On some stepping of SNB cpu, the first command to be parsed in BLT command streamer should be MI_BATCHBUFFER_START otherwise the GPU may hang. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> [ickle: rebased for -next] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-02Revert "drm/i915: add MMIO debug output"Chris Wilson
We can use mmiotrace instead of our own debug printks. This reverts commit be282fd48e7492812402a22d73a348c44bf95b63. Conflicts: drivers/gpu/drm/i915/i915_drv.h
2010-11-02drm/i915: Fix the graphics frequency clamping at init and when IPS is active.Jesse Barnes
Part of the issue here was that Eric slipped in a debug hack for testing the i915 IPS code before the intel_ips.c driver had landed. This caused the driver to always use the full range of frequencies, which is only legal when IPS tells us we have the headroom. Once that hack was removed, there was confusion about the driver's frequency clamping variables: max_delay is the driver's current limit on the highest frequency the IPS driver wants us to use, while dev_priv->fmax is the hardware-reported limit that the IPS driver can increase up to. Tested with IPS driver loaded or not. Note that on Ironlake systems without the IPS driver loaded this will result in a performance reduction, and the inital warmup of frequency limits can impact benchmarking on systems with IPS loaded. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> [ickle: demoted a debugging printk] Cc: stable@kernel.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-02drm/i915: Allow powersave modparam to be adjusted at runtime.Chris Wilson
2.6.36 appears to respect the 0400 mode we assigned to the parameter preventing it from being adjusted after loading. However, this is safe to adjust at runtime. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31311 Reported-by: Fernando Lemos <fernandotcl@gmail.com> Cc: stable@kernel.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-01Merge branch 'drm-intel-fixes' into drm-intel-nextChris Wilson
Conflicts: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem_evict.c
2010-11-01drm/i915: Apply big hammer to serialise buffer access between ringsChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org
2010-11-01drm/i915: Move the invalidate|flush information out of the device structChris Wilson
... and into a local structure scoped for the single function in which it is used. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-01drm/i915: Apply big hammer to serialise buffer access between ringsChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-01drm/i915/debugfs: Report ring in error stateChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-01drm/i915: opregion_setup: iounmap correct addressChristoph Fritz
In case of an opregion signature mismatch in intel_opregion_setup(), iounmap the correct address. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Cc: stable@kernel.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-31drm/i915: Evict just the purgeable GTT entries on the first passChris Wilson
Take two passes to evict everything whilst searching for sufficient free space to bind the batchbuffer. After searching for sufficient free space using LRU eviction, evict everything that is purgeable and try again. Only then if there is insufficient free space (or the GTT is too badly fragmented) evict everything from the aperture and try one last time. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-30drm/i915: Fix typo from e5281ccd in i915_gem_attach_phys_object()Chris Wilson
Accessing the uninitialised obj->pages instead of the local page lead to an OOPs. Reported-by: Xavier Chantry <chantry.xavier@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915: Record BSD engine error stateChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915/ringbuffer: Use the HEAD auto-reporting mechanismChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-29drm/i915: Check if the GPU hung whilst waiting for the ring to clearChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915: Switch to using pci_iounmap in conjunction with pci_iomapChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-29drm/i915/debugfs: Display the contents of the BLT and BSD status pagesChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915/ringbuffer: Remove duplicate initialisation of ring controlChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915: Record BLT engine error stateChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915/ringbuffer: Disable the ringbuffer on cleanup.Chris Wilson
It should be idle on cleanup anyway... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915: Remove the duplicate domain-change tracepoint for GPU flushChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-29drm/i915: Only enforce fence limits inside the GTT.Chris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-29drm/i915: Convert BUG_ON(pin_count) from an impossible conditionChris Wilson
Also spotted by Dan Carpenter. obj->pin_count is unsigned so the BUG_ON(obj->pin_count<0) will never trigger. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-28drm/i915: Do not return -1 from shrinker when nr_to_scan == 0Chris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-28drm/i915: Flush read-only buffers from the active list upon idle as wellChris Wilson
It is possible for the active list to only contain a read-only buffer so that the ring->gpu_write_list remains entry. This leads to an inconsistency between i915_gpu_is_active() and i915_gpu_idle() causing an infinite spin during the shrinker and an assertion failure that i915_gpu_idle() does indeed flush all buffers from the active lists. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-28drm/i915: Kill GTT mappings when moving from GTT domainChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-28drm/i915: Eliminate nested get/put pagesChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-28drm/i915: Remove mmap_offsetChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-28drm/i915: Make the inactive object shrinker per-deviceChris Wilson
Eliminate the racy device unload by embedding a shrinker into each device. Smaller, simpler code. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-28drm/i915/ringbuffer: Check that we setup the ringbufferChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-28drm/i915: Use pci_iomap for remapping the MMIO registers.Chris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Capture ERROR register on Sandybridge hangsChris Wilson
This holds error state from the main graphics arbiter mainly involving the DMA engine and address translation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Use the agp_size determined from the GTTChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Bail early if we try to mmap an object too large to be mapped.Chris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: add accounting for mappable objects in gtt v2Daniel Vetter
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: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: add mappable to gem_object_bind tracepointDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: use the complete gttDaniel Vetter
At least the part that's currently enabled by the BIOS. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: unbind unmappable objects on fault/pinDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: range-restricted bind_to_gttDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: range-restricted eviction supportDaniel Vetter
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 <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm_mm: add support for range-restricted fair-lru scansDaniel Vetter
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Propagate error from failing to queue a requestChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Remove the confusing global waiting/irq seqnoChris Wilson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915/debugfs: Include info for the other ringsChris Wilson
The render ring is not alone any more! And the other rings are just as troublesome... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Fix hangcheck to handle multiple ringsChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Move object to GPU domains after dispatching execbufferChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-27drm/i915: Propagate errors from writing to ringbufferChris Wilson
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 <chris@chris-wilson.co.uk>
2010-10-27i915: signedness bug in check_overlay_src()Dan Carpenter
"depth" should be signed in case packed_depth_bytes() returns -EINVAL. This probably doesn't make a difference at runtime. In the original code we would return -EINVAL later if (rec->offset_Y % 4294967274) is non-zero. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
generated by cgit (git 2.34.1) at 2025-05-30 06:52:13 +0000