1. 18 10月, 2012 1 次提交
    • R
      drm/i915: Insert i915_preliminary_hw_support variable. · 0a3af268
      Rodrigo Vivi 提交于
      On the worst scenario, users with new hardwares and old kernel from
      enabling times can get black screens.  So, from now on, this
      perliminary_hw_support module parameter shall be used by all upcoming
      platforms that are still under enabling. The second option would be to
      merge the pci ids after basic modeset works, but that makes testing
      and development while bringing up hw a rather tedious afair.
      
      Although it is uncomfortable for developers use this extra variable it
      brings more stability for end users.
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Reviewed-by: NDave Airlie <airlied@redhat.com>
      [danvet: dropped the i915_ param prefix, i915.i915_ is just tedious.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0a3af268
  2. 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
  3. 26 9月, 2012 1 次提交
  4. 20 9月, 2012 5 次提交
  5. 06 9月, 2012 2 次提交
    • D
      drm/i915: read out the modeset hw state at load and resume time · 24929352
      Daniel Vetter 提交于
      ... instead of resetting a few things and hoping that this will work
      out.
      
      To properly disable the output pipelines at the initial modeset after
      resume or boot up we need to have an accurate picture of which outputs
      are enabled and connected to which crtcs. Otherwise we risk disabling
      things at the wrong time, which can lead to hangs (or at least royally
      confused panels), both requiring a walk to the reset button to fix.
      
      Hence read out the hw state with the freshly introduce get_hw_state
      functions and then sanitize it afterwards.
      
      For a full modeset readout (which would allow us to avoid the initial
      modeset at boot up) a few things are still missing:
      - Reading out the mode from the pipe, especially the dotclock
        computation is quite some fun.
      - Reading out the parameters for the stolen memory framebuffer and
        wrapping it up.
      - Reading out the pch pll connections - luckily the disable code
        simply bails out if the crtc doesn't have a pch pll attached (even
        for configurations that would need one).
      
      This patch here turned up tons of smelly stuff around resume: We
      restore tons of register in seemingly random way (well, not quite, but
      we're not too careful either), which leaves the hw in a rather
      ill-defined state: E.g. the port registers are sometimes
      unconditionally restore (lvds, crt), leaving us with an active
      encoder/connector but no active pipe connected to it. Luckily the hw
      state sanitizer detects this madness and fixes things up a bit.
      
      v2: When checking whether an encoder with active connectors has a crtc
      wire up to it, check for both the crtc _and_ it's active state.
      
      v3:
      - Extract intel_sanitize_encoder.
      - Manually disable active encoders without an active pipe.
      
      v4: Correclty fix up the pipe<->plane mapping on machines where we
      switch pipes/planes. Noticed by Chris Wilson, who also provided the
      fixup.
      
      v5: Spelling fix in a comment, noticed by Paulo Zanoni
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      24929352
    • D
      drm/i915: add crtc->enable/disable vfuncs insted of dpms · 76e5a89c
      Daniel Vetter 提交于
      Because that's what we're essentially calling. This is the first step
      in untangling the crtc_helper induced dpms handling mess we have - at
      the crtc level we only have 2 states and the magic is just in
      selecting which one (and atm there isn't even much magic, but on
      recent platforms where not even the crt output has more than 2 states
      we could do better).
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      76e5a89c
  6. 03 9月, 2012 1 次提交
  7. 24 8月, 2012 3 次提交
  8. 23 8月, 2012 1 次提交
  9. 21 8月, 2012 1 次提交
    • C
      drm/i915: Track unbound pages · 6c085a72
      Chris Wilson 提交于
      When dealing with a working set larger than the GATT, or even the
      mappable aperture when touching through the GTT, we end up with evicting
      objects only to rebind them at a new offset again later. Moving an
      object into and out of the GTT requires clflushing the pages, thus
      causing a double-clflush penalty for rebinding.
      
      To avoid having to clflush on rebinding, we can track the pages as they
      are evicted from the GTT and only relinquish those pages on memory
      pressure.
      
      As usual, if it were not for the handling of out-of-memory condition and
      having to manually shrink our own bo caches, it would be a net reduction
      of code. Alas.
      
      Note: The patch also contains a few changes to the last-hope
      evict_everything logic in i916_gem_execbuffer.c - we no longer try to
      only evict the purgeable stuff in a first try (since that's superflous
      and only helps in OOM corner-cases, not fragmented-gtt trashing
      situations).
      
      Also, the extraction of the get_pages retry loop from bind_to_gtt (and
      other callsites) to get_pages should imo have been a separate patch.
      
      v2: Ditch the newly added put_pages (for unbound objects only) in
      i915_gem_reset. A quick irc discussion hasn't revealed any important
      reason for this, so if we need this, I'd like to have a git blame'able
      explanation for it.
      
      v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Split out code movements and rant a bit in the commit message
      with a few Notes. Done v2]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6c085a72
  10. 17 8月, 2012 1 次提交
  11. 10 8月, 2012 3 次提交
  12. 26 7月, 2012 12 次提交
  13. 20 7月, 2012 1 次提交
    • C
      drm/i915: Add comments to explain the BSD tail write workaround · 12f55818
      Chris Wilson 提交于
      Having had to dive into the bspec to understand what each stage of the
      workaround meant, and how that the ring broadcasting IDLE corresponded
      with the GT powering down the ring (i.e. rc6) add comments to aide
      the next reader.
      
      And since the register "is used to control all aspects of PSMI and power
      saving functions" that makes it quite interesting to inspect with
      regards to RC6 hangs, so add it to the error-state.
      
      v2: Rediscover the piece of magic, set the RNCID to 0 before waiting for
      the ring to wake up.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      12f55818
  14. 05 7月, 2012 5 次提交
    • D
      drm/i915: introduce for_each_encoder_on_crtc · 6c2b7c12
      Daniel Vetter 提交于
      We already have this pattern at quite a few places, and moving part of
      the modeset helper stuff into the driver will add more.
      
      v2: Don't clobber the crtc struct name with the macro parameter ...
      
      v3: Convert two more places noticed by Paulo Zanoni.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6c2b7c12
    • D
      drm/i915: non-interruptible sleeps can't handle -EAGAIN · d6b2c790
      Daniel Vetter 提交于
      So don't return -EAGAIN, even in the case of a gpu hang. Remap it to
      -EIO instead. Note that this isn't really an issue with
      interruptability, but more that we have quite a few codepaths (mostly
      around kms stuff) that simply can't handle any errors and hence not
      even -EAGAIN. Instead of adding proper failure paths so that we could
      restart these ioctls we've opted for the cheap way out of sleeping
      non-interruptibly.  Which works everywhere but when the gpu dies,
      which this patch fixes.
      
      So essentially interruptible == false means 'wait for the gpu or die
      trying'.'
      
      This patch is a bit ugly because intel_ring_begin is all non-interruptible
      and hence only returns -EIO. But as the comment in there says,
      auditing all the callsites would be a pain.
      
      To avoid duplicating code, reuse i915_gem_check_wedge in __wait_seqno
      and intel_wait_ring_buffer. Also use the opportunity to clarify the
      different cases in i915_gem_check_wedge a bit with comments.
      
      v2: Don't access dev_priv->mm.interruptible from check_wedge - we
      might not hold dev->struct_mutex, making this racy. Instead pass
      interruptible in as a parameter. I've noticed this because I've hit a
      BUG_ON(!mutex_is_locked) at the top of check_wedge. This has been
      added in
      
      commit b4aca010
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Wed Apr 25 20:50:12 2012 -0700
      
          drm/i915: extract some common olr+wedge code
      
      although that commit is missing any justification for this. I guess
      it's just copy&paste, because the same commit add the same BUG_ON
      check to check_olr, where it indeed makes sense.
      
      But in check_wedge everything we access is protected by other means,
      so this is superflous. And because it now gets in the way (we add a
      new caller in __wait_seqno, which can be called without
      dev->struct_mutext) let's just remove it.
      
      v3: Group all the i915_gem_check_wedge refactoring into this patch, so
      that this patch here is all about not returning -EAGAIN to callsites
      that can't handle syscall restarting.
      
      v4: Add clarification what interuptible == fales means in our code,
      requested by Ben Widawsky.
      
      v5: Fix EAGAIN mispell noticed by Chris Wilson.
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d6b2c790
    • P
      drm/i915: get rid of dev_priv->info->has_pch_split · 45e6e3a1
      Paulo Zanoni 提交于
      Previously we had has_pch_split to tell us whether we had a PCH or not
      and we also had dev_priv->pch_type to tell us which kind of PCH it
      was, but it could only be used if we were 100% sure we did have a PCH.
      Now that PCH_NONE was added to dev_priv->pch_type we don't need
      has_pch_split anymore: we can just check for pch_type != PCH_NONE.
      
      The HAS_PCH_{IBX,CPT,LPT} macros use dev_priv->pch_type, so they can
      only be called after intel_detect_pch. The HAS_PCH_SPLIT macro looks
      at dev_priv->info->has_pch_split, which is available earlier.
      
      Since the goal is to implement HAS_PCH_SPLIT using dev_priv->pch_type
      instead of dev_priv->info->has_pch_split, we need to make sure that
      intel_detect_pch is called before any calls to HAS_PCH_SPLIT are made.
      So we moved the intel_detect_pch call to an earlier stage.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      45e6e3a1
    • P
      drm/i915: add PCH_NONE to enum intel_pch · f0350830
      Paulo Zanoni 提交于
      And rely on the fact that it's 0 to assume that machines without a PCH
      will have PCH_NONE as dev_priv->pch_type.
      
      Just today I finally realized that HAS_PCH_IBX is true for machines
      without a PCH. IMHO this is totally counter-intuitive and I don't
      think it's a good idea to assume that we're going to check for
      HAS_PCH_IBX only after we check for HAS_PCH_SPLIT.
      
      I believe that in the future we'll have more PCH types and checks
      like:
      
          if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
      
      will become more and more common. There's a good chance that we may
      break non-PCH machines by adding these checks in code that runs on all
      machines. I also believe that the HAS_PCH_SPLIT check will become less
      common as we add more and more different PCH types. We'll probably
      start replacing checks like:
      
          if (HAS_PCH_SPLIT(dev))
              foo();
          else
              bar();
      
      with:
      
          if (HAS_PCH_NEW(dev))
              baz();
          else if (HAS_PCH_OLD(dev) || HAS_PCH_IBX(dev))
              foo();
          else
              bar();
      
      and this may break gen 2/3/4.
      
      As far as we have investigated, this patch will affect the behavior of
      intel_hdmi_dpms and intel_dp_link_down on gen 4. In both functions the
      code inside the HAS_PCH_IBX check is for IBX-specific workarounds, so
      we should be safe. If we start bisecting gen 2/3/4 bugs to this commit
      we should consider replacing the HAS_PCH_IBX checks with something
      else.
      
      V2: Improve commit message, list possible side effects and solution.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f0350830
    • D
      drm/i915: fix up ilk rc6 disabling confusion · 930ebb46
      Daniel Vetter 提交于
      While creating the new enable/disable_gt_powersave functions in
      
      commit 8090c6b9
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sun Jun 24 16:42:32 2012 +0200
      
          drm/i915: wrap up gt powersave enabling functions
      
      I've botched up the handling of ironlake_disable_rc6. Fix this up by
      calling it at the right place. Note though that ironlake_disable_rc6
      does a bit more than just disabling rc6 - it also tears down all the
      allocated context objects.
      
      Hence we need to move intel_teardown_rc6 out and directly call it from
      intel_modeset_cleanup.
      
      Also properly mark ironlake_enable_rc6 as static and kill the un-used
      declaration in i915_drv.h.
      
      Note: In review a question popped out why disable_rc6 also tears down
      the backing object and why we should move that out - it's simply for
      consistency with gen6+ rps code, which does it that way.
      
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      930ebb46
  15. 04 7月, 2012 1 次提交