Skip to content

L
linux
Switch branch/tag
  1. 22 Jul, 2011 2 commits
  3. 15 Jul, 2011 1 commit
  5. 14 Jul, 2011 5 commits
  7. 13 Jul, 2011 7 commits
  9. 12 Jul, 2011 4 commits
    • Keith Packard's avatar
      Merge branch 'drm-intel-fixes' into drm-intel-next · 9aa73a51
      Keith Packard authored
      9aa73a51
    • Chris Wilson's avatar
      drm/i915/ringbuffer: Idling requires waiting for the ring to be empty · a94919ea
      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: default avatarChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: default avatarEric Anholt <eric@anholt.net>
Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      a94919ea
    • Keith Packard's avatar
      Revert "drm/i915: enable rc6 by default" · 05bd4268
      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: default avatarKeith Packard <keithp@keithp.com>
      05bd4268
    • Keith Packard's avatar
      drm/i915: Clean up i915_driver_load failure path · a7b85d2a
      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: default avatarKeith Packard <keithp@keithp.com>
Tested-by: default avatarLin Ming <ming.m.lin@intel.com>
      a7b85d2a
  11. 11 Jul, 2011 15 commits
  13. 10 Jul, 2011 6 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7