- 22 Aug, 2010 2 commits
-
-
Dave Airlie authored
Like on Sandybridge, disabling the DAC here when doing CRT load detect avoids forever hangs waiting on the hardware. test procedure on HP 2740p: boot with no VGA plugged in, start X, plug in VGA monitor (1280x1024) chvt 3 machine hangs waiting forever. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Eric Anholt <eric@anholt.net>
-
Jesse Barnes authored
Waiting for a hard coded 20ms isn't always enough to make sure a vblank period has actually occurred, so add code to make sure we really have passed through a vblank period (or that the pipe is off when disabling). This prevents problems with mode setting and link training, and seems to fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but on an HP 8440p instead. Hopefully also fixes https://bugs.freedesktop.org/show_bug.cgi?id=29141. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 18 Aug, 2010 4 commits
-
-
Jesse Barnes authored
We need to make sure the eDP PLL is enabled before the pipes or planes, so do it as part of the DP prepare mode set function. Signed-off-by: -
Jesse Barnes authored
We need to use I/O port instructions to access VGA registers on Ironlake+, and it doesn't hurt on other platforms, so switch the VGA plane disable function over to using them. Move it to init time as well while we're at it, no need to repeatedly disable the VGA plane with every mode set and DPMS event. Signed-off-by: -
Jesse Barnes authored
We should disable the panel first when shutting down an eDP link. And when turning one on, the panel needs to be enabled before link training or eDP I/O won't be enabled. Signed-off-by: -
Jesse Barnes authored
Ironlake requires that we clear the reset panel bit during power sequences and restore it afterwards. Uncondtionally add code to do that since it should be harmless on SNB+. Signed-off-by:
-
- 09 Aug, 2010 34 commits
-
-
Zou Nan hai authored
RC6 allows the GPU to enter a lower power state when the GPU is idle. Signed-off-by:
Zou Nan hai <nanhai.zou@intel.com> [anholt: Fixed the !renderctx error path to actually not enable RC6.] Signed-off-by:
-
Chris Wilson authored
If we have failed to ascertain the fixed mode for the LVDS panel, then trust the pixel clock ranges reported for the connection when determing valid modes. This makes intel_sdvo_mode_valid() consistent with intel_lvds_mode_valid() which is also a no-op is there is no fixed mode defined. (Since the mode is both validated by SDVO and LVDS, why are checking against an LVDS fixed mode in SDVO...) By only defining is_lvds to be true when we actually have an LVDS output with a fixed mode, we avoid various potential NULL deferences where the assumption is made that all LVDS outputs have a fixed mode. References: Bug 29449 - [Q35] failure to read EDID/vbios for LVDS, no mode => no output https://bugs.freedesktop.org/show_bug.cgi?id=29449 The primary failure in this bug is not finding the EDID and determining the correct fixed panel mode. However, this patch should fix the secondary issue of not enabling any of the standard modes for the panel either. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Zou Nan hai authored
RC6 power state requires a logical render context in place for saving render context. Signed-off-by:
-
Zou Nan hai authored
This is required by the spec, and without this some 3D programs will hang after resume from RC6 we enable that. Signed-off-by:
-
Chris Wilson authored
If our watchdog fires and we see that the GPU is idle, but that we are still waiting on an interrupt, forcibly wake-up the waiter. i915_do_wait_request() should not be racy, yet there are persistent reports that 945GM hangs whilst the GPU is idle. This implies that the hardware is not quite as coherent as the documentation claims - a write followed by a flush is supposed to be coherent in main memory before the flush is retired and the irq is emitted. This seems to be a sensible and elegant guard to force the wait to timeout. v2: Daniel Vetter pointed out that a warning would be useful to explain why the machine appeared to stall. Signed-off-by:
-
Chris Wilson authored
i830 requires 32bpp cursors to be aligned to 16KB, so we have to expose the alignment parameter to i915_gem_attach_phys_object(). Signed-off-by:
-
Chris Wilson authored
The i845 and i865 have a peculiarlity in that CURBASE is not the trigger for the vsync update of the cursor registers but instead the modification of that register is prohibited whilst the cursor is enabled. Reorder the write sequence for CURPOS, CURCNTR and CURBASE on i845 to i865 to match. v2: Remove the checks for i845/i865 from within i9xx_cursor_update() Signed-off-by:
-
Chris Wilson authored
The FBC is dependent upon a few details of the framebuffer so it is required to be updated within set_base(), so remove the redundant call from mode_set(). Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
Add a new macro, wait_for, to simplify the act of waiting on a register to change state. wait_for() takes three arguments, the condition to inspect on every loop, the maximum amount of time to wait and whether to yield the cpu for a length of time after each check. v2: Upgrade failure messages to DRM_ERROR on the suggestion of Eric Anholt. We do not expect to hit these conditions as they reflect programming errors, so if we do we want to be notified. Signed-off-by:
-
Chris Wilson authored
The cleanup path for early abort failed to nullify the gem_buffer. The likely consequence of this is zero, since a failure here should mean aborting the module load. Signed-off-by:
-
Chris Wilson authored
Previously, we only remembered to update the watermarks for i9xx, and incorrectly assumed that the crtc->enabled flag was valid at that point in the dpms cycle. Note that on my x201s this makes a SR bug on pipe 1 much easier to hit. (Since before this patch when disabling pipe 0, we either didn't update the watermarks at all, or when we did we still thought we had two pipes enabled and so disabled SR.) References: Bug 28969 - [Arrandale] Screen flickers, suspect Self-Refresh https://bugs.freedesktop.org/show_bug.cgi?id=28969Signed-off-by:
-
Chris Wilson authored
Within i915_opregion.c there are two blocks of semantically identical ASLE response codes defined. Only one of those matches the ACPI IGD OpRegion Specification 0.1, use those. Signed-off-by:
Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
shmfs doesn't actually implement i_ops->truncate() so we were not immedatiately releasing the backing pages when shrinking the gfx cache under OOM. Instead use a combination of truncate_inode_pages() and i_ops->truncate_range() as is used by shmem_delete_inode(). Signed-off-by:
-
Chris Wilson authored
Writing to the DSPBASE register triggers the double-buffered update to all the control registers, so always write it last in the update sequence. Signed-off-by:
-
Chris Wilson authored
v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
Directly read the GTT mapping for the contents of the batch buffers rather than relying on possibly stale CPU caches. Also for completeness scan the flushing/inactive lists for the current buffers - we are collecting error state after all. Signed-off-by:
-
Chris Wilson authored
In order to reduce the penalty of fallbacks under memory pressure and to avoid a potential immediate ping-pong of evicting a mmaped buffer, we move the object to the tail of the inactive list when a page is freshly faulted or the object is moved into the CPU domain. We choose not to protect the CPU objects from casual eviction, preferring to keep the GPU active for as long as possible. v2: Daniel Vetter found a bug where I forgot that pinned objects are kept off the inactive list. Signed-off-by:
-
Chris Wilson authored
Based in a large part upon Daniel Vetter's implementation and adapted for handling multiple rings in a single pass. This should lead to better gtt usage and fixes the page-fault-of-doom triggered. The fairness is provided by scanning through the GTT space amalgamating space in rendering order. As soon as we have a contiguous space in the GTT large enough for the new object (and its alignment), evict any object which lies within that space. This should keep more objects resident in the GTT. Doing throughput testing on a PineView machine with cairo-perf-trace indicates that there is very little difference with the new LRU scan, perhaps a small improvement... Except oddly for the poppler trace. Reference: Bug 15911 - Intermittent X crash (freeze) https://bugzilla.kernel.org/show_bug.cgi?id=15911 Bug 20152 - cannot view JPG in firefox when running UXA https://bugs.freedesktop.org/show_bug.cgi?id=20152 Bug 24369 - Hang when scrolling firefox page with window in front https://bugs.freedesktop.org/show_bug.cgi?id=24369 Bug 28478 - Intermittent graphics lockups due to overflow/loop https://bugs.freedesktop.org/show_bug.cgi?id=28478 v2: Attempt to clarify the logic and order of eviction through the use of comments and macros. Signed-off-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
The eviction code is the gnarly underbelly of memory management, and is clearer if kept separated from the normal domain management in GEM. Signed-off-by:
-
Chris Wilson authored
This will be used by the eviction logic to maintain fairness between the rings. Signed-off-by:
-
Daniel Vetter authored
This does two little changes: - Add an alignment parameter for evict_something. It's not really great to whack a carefully sized hole into the gtt with the wrong alignment. Especially since the fallback path is a full evict. - With the inactive scan stuff we need to evict more that one object, so move the unbind call into the helper function that scans for the object to be evicted, too. And adjust its name. No functional changes in this patch, just preparation. Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
In order to properly track bound objects, they need to exist on one of the inactive/active lists or be pinned. As this is a requirement, do the work inside i915_gem_bind_to_gtt() rather than dotted around the callsites. Signed-off-by:
-
Chris Wilson authored
v2: Add the interrupt status and address. Signed-off-by:
-
Chris Wilson authored
Using dev_priv__ avoids sparse complaining about shadowed variables in the *LP_RING() macros. Signed-off-by:
-
Chris Wilson authored
As the function has been reduced to a store plus increment, the body is now smaller than the call so inline it. Signed-off-by:
-
Chris Wilson authored
As we check that the ringbuffer will not wrap upon emission, we do not need to check that incrementing the tail wrapped every time. However, we do upon advancing just in case the tail is now pointing at the very end of the ring. Likewise we can account for the space used during emission in begin() and avoid decrementing it for every emit. Signed-off-by:
-
Chris Wilson authored
The tail is quadword aligned, so we can add two MI_NOOP as a time. Signed-off-by:
-
Chris Wilson authored
This debugging trace was useful for finding the fbcon regression on i965, and it may prove useful again in future. Signed-off-by:
-
Chris Wilson authored
The comments have long desired that we should switch off the cursor along with the display plane, make it so. Signed-off-by:
-
Daniel Vetter authored
My i855GM suffers from a 80k/s interrupt storm without this. So add 2nd gen to the list of things that don't like more than one outstanding pageflip request. Furthermore I've changed the busy loop into a ringbuffer wait. Busy-loops that don't check whether the chip died are simply evil. And performance should actually improve, because there's usually a decent amount of rendering queued on the gpu, hopefully rendering that MI_WAIT into a noop by the time it's executed. The current code holds dev->struct_mutex while executing this loop, hence stalling all other gem activity anyway. Signed-off-by:
-
Daniel Vetter authored
Add a new path for 2nd gen chips that uses the commands for i81x chips (where public docs do exist) augmented with the plane bits from i915. It seems to work and doesn't result in a black screen like before. Signed-off-by:
-
