1. 02 8月, 2010 6 次提交
  2. 27 7月, 2010 1 次提交
  3. 20 7月, 2010 1 次提交
  4. 02 7月, 2010 1 次提交
    • A
      drm/i915: Fix CRT hotplug regression in 2.6.35-rc1 · 2d1c9752
      Andy Lutomirski 提交于
      Commit 7a772c49 has two bugs which
      made the hotplug problems on my laptop worse instead of better.
      
      First, it did not, in fact, disable the CRT plug interrupt -- it
      disabled all the other hotplug interrupts.  It seems rather doubtful
      that that bit of the patch fixed anything, so let's just remove it.
      (If you want to add it back, you probably meant ~CRT_HOTPLUG_INT_EN.)
      
      Second, on at least my GM45, setting CRT_HOTPLUG_ACTIVATION_PERIOD_64
      and CRT_HOTPLUG_VOLTAGE_COMPARE_50 (when they were previously unset)
      causes a hotplug interrupt about three seconds later.  The old code
      never restored PORT_HOTPLUG_EN so this could only happen once, but
      they new code restores those registers.  So just set those bits when
      we set up the interrupt in the first place.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      2d1c9752
  5. 19 6月, 2010 1 次提交
  6. 29 5月, 2010 1 次提交
  7. 27 5月, 2010 5 次提交
  8. 08 5月, 2010 1 次提交
    • A
      drm/i915: Use spatio-temporal dithering on PCH · 0a31a448
      Adam Jackson 提交于
      Spatial dither is better than nothing, but ST is even better.
      
      (from ajax's followup message:)
        I noticed this with:
      
        http://ajax.fedorapeople.org/YellowFlower.jpg
      
        set as my desktop background in Gnome on a 1280x800 machine (in
        particular, a Sony Vaio VPCB1 with 6-bit panel and a rather bright black
        level).  Easiest way to test this is by poking at PIPEACONF with
        intel_reg_write directly:
      
        % sudo intel_reg_write 0x70008 0xc0000040 # no dither
        % sudo intel_reg_write 0x70008 0xc0000050 # spatial
        % sudo intel_reg_write 0x70008 0xc0000054 # ST
      
        I notice it especially strongly in the relatively flat dark area in the
        top left.  Closer than about 18" I can see a noticeable checkerboard
        pattern with plain spatial dithering.  ST smooths that out; I can still
        tell that it's lacking color precision, but it's not offensive.
      Signed-off-by: NAdam Jackson <ajax@redhat.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      0a31a448
  9. 23 4月, 2010 1 次提交
  10. 19 4月, 2010 1 次提交
    • D
      drm/i915: fix tiling limits for i915 class hw v2 · c36a2a6d
      Daniel Vetter 提交于
      Current code is definitely crap: Largest pitch allowed spills into
      the TILING_Y bit of the fence registers ... :(
      
      I've rewritten the limits check under the assumption that 3rd gen hw
      has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an
      otherwise totally misleading XXX comment.
      
      This bug mostly resulted in tiling-corrupted pixmaps because the kernel
      allowed too wide buffers to be tiled. Bug brought to the light by the
      xf86-video-intel 2.11 release because that unconditionally enabled
      tiling for pixmaps, relying on the kernel to check things. Tiling for
      the framebuffer was not affected because the ddx does some additional
      checks there ensure the buffer is within hw-limits.
      
      v2: Instead of computing the value that would be written into the
      hw fence registers and then checking the limits simply check whether
      the stride is above the 8kb limit. To better document the hw, add
      some WARN_ONs in i915_write_fence_reg like I've done for the i830
      case (using the right limits).
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449Tested-by: NAlexander Lam <lambchop468@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NEric Anholt <eric@anholt.net>
      c36a2a6d
  11. 13 4月, 2010 4 次提交
  12. 19 3月, 2010 1 次提交
  13. 18 3月, 2010 2 次提交
  14. 27 2月, 2010 3 次提交
  15. 23 2月, 2010 4 次提交
    • C
      drm/i915: Record batch buffer following GPU error · 9df30794
      Chris Wilson 提交于
      In order to improve our diagnostic capabilities following a GPU hang
      and subsequent reset, we need to record the batch buffer that triggered
      the error. We assume that the current batch buffer, plus a few details
      about what else is on the active list, will be sufficient -- at the very
      least an improvement over nothing.
      
      The extra information is stored in /debug/dri/.../i915_error_state
      following an error, and may be decoded using
      intel_gpu_tools/tools/intel_error_decode.
      
      v2: Avoid excessive work under spinlocks.
      v3: Include ringbuffer for later analysis.
      v4: Use kunmap correctly and record more buffer state.
      v5: Search ringbuffer for current batch buffer
      v6: Use a work fn for the impossible IRQ error case.
      v7: Avoid non-atomic paths whilst in IRQ context.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      9df30794
    • M
      drm/i915: Deobfuscate the render p-state obfuscation · b5b72e89
      Matthew Garrett 提交于
      The ironlake render p-state support includes some rather odd variable
      names. Clean them up in order to improve the readability of the code.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      b5b72e89
    • J
      drm/i915: add dynamic performance control support for Ironlake · f97108d1
      Jesse Barnes 提交于
      Ironlake (and 965GM, which this patch doesn't support) supports a
      hardware performance and power management feature that allows it to
      adjust to changes in GPU load over time with software help.  The goal
      if this is to maximize performance/power for a given workload.
      
      This patch enables that feature, which is also a requirement for
      supporting Intelligent Power Sharing, a feature which allows for
      dynamic budgeting of power between the CPU and GPU in Arrandale
      platforms.
      Tested-by: Nykzhao <yakui.zhao@intel.com>
      [anholt: Resolved against the irq handler loop removal]
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      f97108d1
    • L
      drm/i915: enable memory self refresh on 9xx · ee980b80
      Li Peng 提交于
      Enabling memory self refresh (SR) on 9xx needs to set additional
      register bits. On 945, we need bit 31 of FW_BLC_SELF to enable the
      write to self refresh bit and bit 16 to enable the write of self
      refresh watermark. On 915, bit 12 of INSTPM is used to enable SR.
      
      SR will take effect when CPU enters C3+ state and its entry/exit
      should be automatically controlled by H/W, driver only needs to set
      SR enable bits in wm update. But this isn't safe in my test on 945
      because GPU is hung. So this patch explicitly enables SR when GPU
      is idle, and disables SR when it is busy. In my test on a netbook of
      945GSE chipset, it saves about 0.8W idle power.
      Signed-off-by: NLi Peng <peng.li@intel.com>
      [anholt: rebased against 33c5fd12
      by adding disable of INSTPM SR bit on 915GM for two pipe setup]
      Signed-off-by: NEric Anholt <eric@anholt.net>
      ee980b80
  16. 11 2月, 2010 1 次提交
  17. 16 1月, 2010 1 次提交
  18. 07 1月, 2010 1 次提交
  19. 17 12月, 2009 1 次提交
  20. 08 12月, 2009 1 次提交
  21. 02 12月, 2009 2 次提交