- 14 Jul, 2011 2 commits
-
-
Ben Widawsky authored
Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
Ben Widawsky authored
Signed-off-by:
-
- 13 Jul, 2011 5 commits
-
-
Chris Wilson authored
Alan Cox reported a missing check on the kmalloc return value for the allocation of a temporary mode used for searching for the LVDS downlock frequency. This allocation is roughly 200 bytes, a little too large to friviously place on the stack. However, we can simply use the few bytes we need stored within the original DVO timing data, skip the translation and do the compare directly between the timing data rather than on a mode, thus avoiding the need for any temporary allocations. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Keith Packard <keithp@keithp.com> Signed-off-by:
-
Chris Wilson authored
The read back of the available FIFO entries is vital for system stability, but extremely costly. However, we only need a guide so as to avoid eating into the reserved entries and since we are the only consumer we can cache the read of the count from the last write. Signed-off-by:
-
Matthew Garrett authored
opregion-based platforms will send ACPI video event 0x80 for a range of notification types for legacy compatibility. This is interpreted as a display switch event, which may not be appropriate in the circumstances. When we receive such an event we should make sure that the platform is genuinely requesting a display switch before passing that event through to userspace. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Tested-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Keith Packard authored
Do not use this bit to indicate that load detection has completed, instead just wait for vblank, at which point the load registers will have been updated. Signed-off-by:
Yi Sun <yi.sun@intel.com>
-
Keith Packard authored
Signed-off-by:
-
- 12 Jul, 2011 4 commits
-
-
Keith Packard authored
-
Chris Wilson authored
...which is measured by the size and not the amount of space remaining. Waiting upon size-8, did one of two things. In the common case with more than 8 bytes available to write into the ring, it would return immediately. Otherwise, it would timeout given the impossible condition of waiting for more space than is available in the ring, leading to warnings such as: [drm:intel_cleanup_ring_buffer] *ERROR* failed to quiesce render ring whilst cleaning up: -16 Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Keith Packard authored
This reverts commit a51f7a66. We still have a few Ironlake and Sandybridge machines which fail when RC6 is enabled. Better luck next release? Signed-off-by:
-
Keith Packard authored
i915_driver_load adds a write-combining MTRR region for the GTT aperture to improve memory speeds through the aperture. If i915_driver_load fails after this, it would not have cleaned up the MTRR. This shouldn't cause any problems, except for consuming an MTRR register. Still, it's best to clean up completely in the failure path, which is easily done by calling mtrr_del if the mtrr was successfully allocated. i915_driver_load calls i915_gem_load which register i915_gem_inactive_shrink. If i915_driver_load fails after calling i915_gem_load, the shrinker will be left registered. When called, it will access freed memory and crash. The fix is to unregister the shrinker in the failure path using code duplicated from i915_driver_unload. i915_driver_load also has some incorrect gotos in the error cleanup paths: * After failing to initialize the GTT (which cannot happen, btw, intel_gtt_get returns a fixed (non-NULL) value), it tries to free the uninitialized WC IO mapping. Fixed this by changing the target from out_iomapfree to out_rmmap Signed-off-by:
Lin Ming <ming.m.lin@intel.com>
-
- 08 Jul, 2011 9 commits
-
-
Keith Packard authored
We'll try again with the new fixes. Prepare to see this reverted when we get regression reports... Signed-off-by: -
Chris Wilson authored
Upon review, all path share the same dependencies for updating the registers and so we can benefit from sharing the code and checking early. This removes the unsightly intel_wait_for_vblank() from the lowlevel functions and upon further analysis the only path that will require a wait is if we are performing an instantaneous transition between two valid FBC configurations. The page-flip path itself will have disabled FBC registers and will have waited for at least one vblank before finishing the flip and attempting to re-enable FBC. This wait can be accomplished simply by delaying the enable until after we are sure that a vblank will have passed, which we are already doing to make sure that the display is settled before enabling FBC. Signed-off-by:
-
Chris Wilson authored
In order to accommodate the requirements of re-enabling FBC after page-flipping, but to avoid doing so and incurring the cost of a wait for vblank in the middle of a page-flip sequence, we defer the actual enablement by 50ms. If any request to disable FBC arrive within that interval, the enablement is cancelled and we are saved from blocking on the wait. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Chris Wilson authored
Page-flipping updates the scanout address, nukes the FBC compressed image and so forces an FBC update so that the displayed image remains consistent. However, page-flipping does not update the FBC registers themselves, which remain pointing to both the old address and the old CPU fence. Future updates to the new front-buffer (scanout) are then undetected! This first approach to demonstrate the issue and highlight the fix, simply disables FBC upon page-flip (a recompression will be forced on every flip so FBC becomes immaterial) and then re-enables FBC in the page-flip finish work function, so that the FBC registers are now pointing to the new framebuffer and front-buffer rendering works once more. Ideally, we want to only re-enable FBC after page-flipping is complete, as otherwise we are just wasting cycles and power (with needless recompression) whilst the page-flipping application is still running. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33487Signed-off-by:
-
Chris Wilson authored
Persistent mode is intended for use with front-buffer rendering, such as X, where it is necessary to detect writes to the scanout either by the GPU or through the CPU's fence, and recompress the dirty regions on the fly. (By comparison to the back-buffer rendering, the scanout is always recompressed after a page-flip.) References: https://bugs.freedesktop.org/show_bug.cgi?id=33487 References: https://bugs.freedesktop.org/show_bug.cgi?id=31742Signed-off-by:
-
Chris Wilson authored
...and this requirement is enforced by intel_update_fbc() so we can remove the later check from g4x_enable_fbc() and ironlake_enable_fbc(). Signed-off-by:
-
Chris Wilson authored
The cfb_pitch was only used for 8xx_enable_fbc(), every later routine was just overwriting the value with itself thanks to a copy'n'paste error. Signed-off-by:
-
Chris Wilson authored
...to ensure that any pending FBC enable tasklet is cancelled. Signed-off-by:
-
Chris Wilson authored
As the enable/disable routines will be gain additional complexity in future patches, it is necessary that all callers do not bypass the generic interface by calling into the chipset routines directly. to do this we make the chipset routines static, so there is no choice. Signed-off-by:
-
- 07 Jul, 2011 20 commits
-
-
Keith Packard authored
-
Kenneth Graunke authored
According to the hardware documentation, GDRST is exactly the same as on Sandybridge. So simply enable the existing code. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Keith Packard authored
-
Jesse Barnes authored
On sinks with a DPCD rev of 1.1 or greater, we can send sink power management commands to address 0x600 per section 5.1.5 of the DisplayPort 1.1a spec. Signed-off-by:
-
Jesse Barnes authored
When checking link status during a hot plug event or detecting sink presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a DisplayPort spec). Consolidate the retry code into a native_aux_read_retry function for use by get_link_status and _detect. Signed-off-by:
-
Jesse Barnes authored
We currently use this when a hot plug event is received, only checking the link status and re-training if we had previously configured a link. However if we want to preserve the DP configuration across both hot plug and DPMS events (which we do for userspace apps that don't respond to hot plug uevents), we need to unconditionally check the link and try to bring it up on hot plug. Signed-off-by:
-
Jesse Barnes authored
If ->detect is called too soon after a hot plug event, the sink may not be ready yet. So try up to 3 times with 1ms sleeps in between tries to get the data (spec dictates that receivers must be ready to respond within 1ms and that sources should try 3 times). See section 9.1 of the 1.1a DisplayPort spec. Signed-off-by:
-
Jesse Barnes authored
When a hotplug event is received, we need to check the receiver cap bits in case they've changed (as they might with a hub or chain config). Signed-off-by:
-
Jesse Barnes authored
Makes it easier to search for DP related constants. Reviewed-by:
-
Jesse Barnes authored
Especially after a hotplug or power status change, the sink may not reply immediately to a link status query. So retry 3 times per the spec to really make sure nothing is there. See section 9.1 of the 1.1a DisplayPort spec. Signed-off-by:
-
Jesse Barnes authored
Now that we track bpp on a per-pipe basis, we can use the actual value rather than assuming 24bpp. Signed-off-by:
-
Jesse Barnes authored
This will catch bad fb configs earlier. Signed-off-by:
-
Jesse Barnes authored
To properly drive a framebuffer with a new depth or bpp, dither settings and link bandwidth calculations may change, so make sure we go through a full mode set in that case. Reported-by:
-
Jesse Barnes authored
The Intel HDMI encoder can support 8bpc or 12bpc. Set the appropriate value based on the pipe bpp when configuring the output. Signed-off-by:
-
Jesse Barnes authored
The pipe may be driving various bpp values depending on the display configuration, so take that into account when calculating link bandwidth requirements. Signed-off-by:
-
Jesse Barnes authored
Updating the planes is device specific, so create a new display callback and use it in pipe_set_base. (In fact we could go even further, valid display plane bits have changed with each generation, as has tiled buffer handling.) Signed-off-by:
-
Jesse Barnes authored
Figuring out which pipe bpp to use is a bit painful. It depends on both the encoder and display configuration attached to a pipe. For instance, to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc on the pipe but also enable dithering. But driving that same framebuffer to a DisplayPort output on another pipe means using 8bpc and no dithering. So split out and enhance the code to handle the various cases, returning an appropriate pipe bpp as well as whether dithering should be enabled. Save the resulting pipe bpp in the intel_crtc struct for use by encoders in calculating bandwidth requirements (defaults to 24bpp on pre-ILK). Signed-off-by:
-
Jesse Barnes authored
This may not be the default value, so pull the bpc out of the pipe reg and write it to the DP transcoder so proper dithering and signaling occurs. Signed-off-by:
-
Jesse Barnes authored
This prevents us from setting reserved or incorrect bits on CougarPoint. Signed-off-by:
-
Jesse Barnes authored
These bits are reserved on ILK+ (ILK+ provides this feature in the transcoder and pipe configuration instead, which we already set). Signed-off-by:
-
