1. 15 1月, 2013 1 次提交
  2. 20 12月, 2012 1 次提交
    • D
      drm/i915: optionally disable shrinker lock stealing · 677feac2
      Daniel Vetter 提交于
      commit 5774506f
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed Nov 21 13:04:04 2012 +0000
      
          drm/i915: Borrow our struct_mutex for the direct reclaim
      
      added a nice trick to steal the struct_mutex lock in the shrinker if
      it's the current task holding it. But this also caused the requirement
      that every place which allocates memory needs to be careful about the
      gem state of objects, since the shrinker could have pulled the rug out
      from under it. We've usually solved this by carefully preallocating
      things or ensure that buffers are pinned already.
      
      But the shrinker also reaps mmap offset, so allocating those needs to
      be careful, too. Now that code has been factored out into some common
      helpers, so either we have fragile code depending upon the common
      helper not doing something we don't want it to do. Or we need to
      reimplement the mmap offset creation and so also leak implementation
      details into our code.
      
      Since this all results in leaky abstraction, cop out by disabling the
      lock borrowing trick while calling down into the helpers. That way our
      craziness is nicely confined to files in drm/i915.
      
      v2: Split out the change to create_mmap_offset as request by Chris Wilson.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      677feac2
  3. 18 12月, 2012 2 次提交
    • D
      drm/i915: Implement workaround for broken CS tlb on i830/845 · b45305fc
      Daniel Vetter 提交于
      Now that Chris Wilson demonstrated that the key for stability on early
      gen 2 is to simple _never_ exchange the physical backing storage of
      batch buffers I've tried a stab at a kernel solution. Doesn't look too
      nefarious imho, now that I don't try to be too clever for my own good
      any more.
      
      v2: After discussing the various techniques, we've decided to always blit
      batches on the suspect devices, but allow userspace to opt out of the
      kernel workaround assume full responsibility for providing coherent
      batches. The principal reason is that avoiding the blit does improve
      performance in a few key microbenchmarks and also in cairo-trace
      replays.
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet:
      - Drop the hunk which uses HAS_BROKEN_CS_TLB to implement the ring
        wrap w/a. Suggested by Chris Wilson.
      - Also add the ACTHD check from Chris Wilson for the error state
        dumping, so that we still catch batches when userspace opts out of
        the w/a.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b45305fc
    • D
      drm/i915: Implement WaSetupGtModeTdRowDispatch · 6547fbdb
      Daniel Vetter 提交于
      I'm not really sure, since the w/a entry is as thin on details as
      ever, and Bspec doesn't say anything about it. But I've figured only
      dispatching to rows 0&1 instead of all four should be the right thing
      for GT1.
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      [danvet: Add the missing snb server GT1 to the check, spotted by Chris
      Wilson.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6547fbdb
  4. 10 12月, 2012 3 次提交
  5. 29 11月, 2012 3 次提交
  6. 22 11月, 2012 4 次提交
  7. 13 11月, 2012 1 次提交
    • C
      drm/i915/i2c: Track users of GMBUS force-bit · f2ce9faf
      Chris Wilson 提交于
      This fixes a regression for SDVO from
      
      commit fbfcc4f3
      Author: Jani Nikula <jani.nikula@intel.com>
      Date:   Mon Oct 22 16:12:18 2012 +0300
      
          drm/i915/sdvo: restore i2c adapter config on intel_sdvo_init() failures
      
      As SDVOB and SDVOC are multiplexed on the same pin, if a chipset does
      not have the second SDVO encoder, it will then remove the force-bit
      setting on the common i2c adapter during teardown. All subsequent
      attempts of trying to use GMBUS with SDVOB then fail.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      [danvet: fixup inversion in the debug printout, noticed by Jani
      Nikulai.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f2ce9faf
  8. 12 11月, 2012 13 次提交
  9. 26 10月, 2012 1 次提交
    • P
      drm/i915: add TRANSCODER_EDP · a5c961d1
      Paulo Zanoni 提交于
      Before Haswell we used to have the CPU pipes and the PCH transcoders.
      We had the same amount of pipes and transcoders, and there was a 1:1
      mapping between them. After Haswell what we used to call CPU pipe was
      split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
      B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
      (only used for VGA).
      
      For all the outputs except for EDP we have an 1:1 mapping on the CPU
      pipes and CPU transcoders, so if you're using CPU pipe A you have to
      use CPU transcoder A. When have an eDP output you have to use
      transcoder EDP and you can attach this CPU transcoder to any of the 3
      CPU pipes. When using VGA you need to select a pair of matching CPU
      pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
      PCH transcoder.
      
      For now we're just creating the cpu_transcoder definitions and setting
      cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
      registers was ported to use transcoder instead of pipe. The goal is to
      keep the code backwards-compatible since on all cases except when
      using eDP we must have pipe == cpu_transcoder.
      
      V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
      and Daniel Vetter.
      
      We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
      can be used by any CRTC, so when you stop using it you have to stop
      saying you're using it, otherwise you may have at some point 2 CRTCs
      claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
      one), then the HW state readout code will get completely confused.
      
      In other words:
      
      Imagine the following case:
        xrandr --output eDP1 --auto --crtc 0
        xrandr --output eDP1 --off
        xrandr --output eDP1 --auto --crtc 2
      
      After the last command you could get a "pipe A assertion failure
      (expected off, current on)" because CRTC 0 still claims it's using
      TRANSCODER_EDP, so the HW state readout function will read it
      (through PIPECONF) and expect it to be off, when it's actually on
      because it's being used by CRTC 2.
      
      So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
      make sure we're pointing to our own original CRTC which is certainly
      not used by any other CRTC.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a5c961d1
  10. 23 10月, 2012 3 次提交
  11. 18 10月, 2012 2 次提交
  12. 16 10月, 2012 1 次提交
  13. 12 10月, 2012 2 次提交
    • C
      drm/i915: fixup i915_gem_object_get_page inline helper · 1cf83789
      Chris Wilson 提交于
      Note that just because we have n == MAX elements left, does not imply
      that there are only MAX elements left in the scatterlist and so we may
      not be on the last chain, and the nth element may in fact be a chain ptr.
      
      This is exercised by the improved hangman tests and the gem_exec_big
      test in i-g-t.
      
      This regression has been introduced in
      
      commit 9da3da66
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Jun 1 15:20:22 2012 +0100
      
         drm/i915: Replace the array of pages with a scatterlist
      
      v2: KISS, replace the direct lookup with a for_each_sg() [danvet]
      v3: Try to be clever again.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1cf83789
    • C
      drm/i915: Disallow preallocation of requests · acb868d3
      Chris Wilson 提交于
      The intention was to allow the caller to avoid a failure to queue a
      request having already written commands to the ring. However, this is a
      moot point as the i915_add_request() can fail for other reasons than a
      mere allocation failure and those failure cases are more likely than
      ENOMEM. So the overlay code already had to handle i915_add_request()
      failures, and due to
      
      commit 3bb73aba
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Jul 20 12:40:59 2012 +0100
      
          drm/i915: Allow late allocation of request for i915_add_request()
      
      the error handling code in intel_overlay.c was subject to causing
      double-frees, as found by coverity.
      
      Rather than further complicate i915_add_request() and callers, realise
      the battle is lost and adapt intel_overlay.c to take advantage of the
      late allocation of requests.
      
      v2: Handle callers passing in a NULL seqno.
      v3: Ditto. This time for sure.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      acb868d3
  14. 10 10月, 2012 1 次提交
    • P
      drm/i915: completely rewrite the Haswell PLL handling code · 6441ab5f
      Paulo Zanoni 提交于
      Problems with the previous code:
        - HDMI just uses WRPLL1 for everything, so dual head cases might not
          work sometimes.
        - At encoder->mode_set we just write the PLL register without doing
          any kind of check (e.g., check if the PLL is already being used).
        - There is no way to fail and return error codes at
          encoder->mode_set.
        - We write to PORT_CLK_SEL at mode_set and we never disable it.
        - Machines hang due to wrong clock enable/disable sequence.
      
      So here we rewrite the code, making it a little more like the
      pre-Haswell PLL mode set code:
        - Check PLL availability at ironlake_crtc_mode_set.
        - Try to use both WRPLLs.
        - Check if PLLs are used before actually trying to use them, and
          properly fail with error messages.
        - Enable/disable PORT_CLK_SEL at the right place.
        - Add some WARNs to check for bugs.
      
      The next improvement will be to try to reuse PLLs if the timings
      match, but this is content for another patch and it's already
      documented with a TODO comment.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6441ab5f
  15. 09 10月, 2012 1 次提交
  16. 26 9月, 2012 1 次提交