- 15 Nov, 2010 2 commits
-
-
Chris Wilson authored
As we may bind an object with the correct alignment, but with an invalid size, it may pass the current checks on whether the object may be reused with a fence. Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk>
-
Daniel Vetter authored
g33/pineview doesn't have any alignment constrains for unfenced tiled buffers. But older chips have. Fix this. Problem introduced in a00b10c3. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 Nov, 2010 4 commits
-
-
Chris Wilson authored
We only ever used the PRB0, neglecting the secondary ring buffers, and now with the advent of multiple engines with separate ring buffers we need to excise the anachronisms from our code (and be explicit about which ring we mean where). This is doubly important in light of the FORCEWAKE required to read ring buffer registers on SandyBridge. Signed-off-by: -
Chris Wilson authored
This reverts commit 629e8941.
-
Zou Nan hai authored
Before reading ring register, set FORCE_WAKE bit to prevent GT core power down to low power state, otherwise we may read stale values. Signed-off-by:
Zou Nan hai <nanhai.zou@intel.com> [ickle: added a udelay which seemed to do the trick on my SNB] Signed-off-by:
-
Chris Wilson authored
... as it has been replaced by per-ring waiters. Signed-off-by:
-
- 10 Nov, 2010 2 commits
-
-
Chris Wilson authored
Signed-off-by: -
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:
-
- 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 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 4 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:
-
