- 10 Nov, 2010 2 commits
-
-
Chris Wilson authored
Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk>
-
Chris Wilson authored
We use i915_gem_object_get_fence_reg() to do LRU tracking of the fence registers, so stop trying to be too clever when pinning the fb->obj. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 08 Nov, 2010 7 commits
-
-
Chris Wilson authored
If modeset init failed we attempted to unload the module, before we finished setting it up and so triggered various oopses. Signed-off-by: -
Chris Wilson authored
As we use POSTING_READ to flush the write to the register before proceeding, we do not care what the return value is and similar we do not care for the read to be recorded whilst tracing register read/writes. Signed-off-by: -
Yuanhan Liu authored
These registers are written very frequently, are timing sensitive, and not particularly relevant to any debugging, so remove the tracepoints from these. Signed-off-by:
Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by:
-
Yuanhan Liu authored
This will be used later to hide the frequently written registers from debug traces in order to increase the signal-to-noise. Signed-off-by:
-
Yuanhan Liu authored
Add two tracepoints at I915_WRITE/READ for tracing down all the register write and read. Signed-off-by:
-
Eric Anholt authored
Not known to fix any current bugs. Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Eric Anholt authored
This is not known to fix any particular bugs we have, but the spec says to do it, and the BIOS hadn't already set it up on my system. Signed-off-by:
-
- 07 Nov, 2010 3 commits
-
-
Chris Wilson authored
The ring buffer registers return 0 whilst idle (for some values of idle) on early Sandybridge hw. Persevere even when all appears hopeless... Fortunately the head auto-reporting prevents most hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31370Signed-off-by:
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Instead of killing the process, just return no page found and reschedule the process giving the GPU some time to (hopefully) recover. Signed-off-by:
-
- 04 Nov, 2010 7 commits
-
-
Daniel Vetter authored
a00b10c3 "Only enforce fence limits inside the GTT" also added a fenceable/mappable disdinction when binding/pinning buffers. This only complicates the code with no pratical gain: - In execbuffer this matters on for g33/pineview, as this is the only chip that needs fences and has an unmappable gtt area. But fences are only possible in the mappable part of the gtt, so need_fence implies need_mappable. And need_mappable is only set independantly with relocations which implies (for sane userspace) that the buffer is untiled. - The overlay code is only really used on i8xx, which doesn't have unmappable gtt. And it doesn't support tiled buffers, currently. - For all other buffers it's a bug to pass in a tiled bo. In short, this disdinction doesn't have any practical gain. I've also reverted mapping the overlay and context pages as possibly unmappable. It's not worth being overtly clever here, all the big gains from unmappable are for execbuf bos. Also add a comment for a clever optimization that confused me while reading the original patch by Chris Wilson. Signed-off-by:
-
Daniel Vetter authored
In a00b10c3 "Only enforce fence limits inside the GTT" Chris Wilson implemented an optimization to only pin framebuffers as mappable for crtc_set_base (but not for pageflips). This breaks the abi, eg: A double buffering mesa client might leave the last framebuffer in unmappable space on close. A subsequent glReadPix by a frontbuffer rendering client then goes boom. My pretty anal mappable/unmappable consistency checking detected this, see https://bugs.freedesktop.org/show_bug.cgi?id=31286 Chris Wilson tried to fix this in 085ce264 by pinning tiled framebuffers into mappable space. This a) renders the original optimization of not forcing framebuffers for pageflipping clients into mappable pointless because all our scanout buffers are tiled by default. b) doesn't solve the problem for untiled framebuffers. So kill this. Emperically it's no gain anyway because framebuffers are being reused by the ddx and hence there's no chance for them to get constanly bounced between mappable and unmappable. Signed-off-by:
-
Chris Wilson authored
-
Zhenyu Wang authored
This is broken from 97ef1bdd. Let's set the correct bit for LLC+MLC and LLC only. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Cc: stable@kernel.org Signed-off-by:
-
Zhenyu Wang authored
This restores cache behavior for default AGP_USER_MEMORY as uncached, and leave default AGP_USER_CACHED_MEMORY as LLC only. I've seen different cache behavior on one sandybridge desktop CPU vs. another mobile CPU. Until we figure out how to detect the real cache config, restore back to the original behavior now. Signed-off-by:
-
Zhenyu Wang authored
Signed-off-by:
Zhenyu Wang <zhenyu.z.wang@intel.com> Cc: stable@kernel.org Signed-off-by:
-
Zhenyu Wang authored
We should enable FDI normal training on Sandybridge/CPT system as well. Signed-off-by:
-
- 03 Nov, 2010 2 commits
-
-
Kyle McMartin authored
Fixes issue where i915_gfx_val was reporting values several orders of magnitude higher than physically possible (without leaving scorch marks on my thighs at least.) Signed-off-by:
Kyle McMartin <kyle@redhat.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by:
-
Chris Wilson authored
When merging Daniel's full-gtt patches I had a set of tweaks which I thought I had undone. I was half right... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31286 Reported-by: jinjin.wang@intel.com Reported-by:
Alexey Fisher <bug-track@fisher-privat.net> Signed-off-by:
-
- 02 Nov, 2010 9 commits
-
-
Chris Wilson authored
I presumed that we would be writing to the batch through the GTT having bound it, so I converted it to use iomem. Even later as I spotted that we didn't even move the batch to the GTT (now an issue since we default to uncached memory on SNB) I still didn't realise that using iomem for kmapped memory was incorrect. Fix it. Signed-off-by: -
Chris Wilson authored
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
-
Chris Wilson authored
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 8d19215b) 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:
-
Zou Nan hai authored
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:
-
Zhenyu Wang authored
This restores cache behavior for default AGP_USER_MEMORY as uncached, and leave default AGP_USER_CACHED_MEMORY as LLC only. I've seen different cache behavior on one sandybridge desktop CPU vs. another mobile CPU. Until we figure out how to detect the real cache config, restore back to the original behavior now. Signed-off-by:
-
Zhenyu Wang authored
This is broken from 97ef1bdd. Let's set the correct bit for LLC+MLC and LLC only. Signed-off-by:
-
Chris Wilson authored
We can use mmiotrace instead of our own debug printks. This reverts commit be282fd4. Conflicts: drivers/gpu/drm/i915/i915_drv.h
-
Jesse Barnes authored
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:
-
Chris Wilson authored
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=31311Reported-by:
Fernando Lemos <fernandotcl@gmail.com> Cc: stable@kernel.org Signed-off-by:
-
- 01 Nov, 2010 6 commits
-
-
Chris Wilson authored
Conflicts: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem_evict.c
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
... and into a local structure scoped for the single function in which it is used. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Christoph Fritz authored
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:
-
- 31 Oct, 2010 2 commits
-
-
Chris Wilson authored
... and trying to set the bit is ineffectual. Fixes the regression from e380f60b which detected that we were trying to do undefined operations on the I830_GMCH_CTRL. Reported-by:
-
Chris Wilson authored
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:
-
- 30 Oct, 2010 1 commit
-
-
Chris Wilson authored
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:
-
- 29 Oct, 2010 1 commit
-
-
Chris Wilson authored
Signed-off-by:
-
