1. 03 6月, 2013 1 次提交
  2. 01 6月, 2013 2 次提交
  3. 24 5月, 2013 2 次提交
  4. 23 5月, 2013 1 次提交
  5. 23 4月, 2013 2 次提交
  6. 18 4月, 2013 4 次提交
    • J
      drm/i915: turbo & RC6 support for VLV v7 · 0a073b84
      Jesse Barnes 提交于
      Uses slightly different interfaces than other platforms.
      
      v2: track actual set freq, not requested (Rohit)
          fix debug prints in init code (Jesse)
      v3: don't write sleep reg (Jesse)
          re-add RC6 wake limit write (Ben)
          fixup thresholds to match other platforms (Ben)
          clean up mem freq calculation (Ben)
          clean up debug prints (Ben)
      v4: move defines from punit patch (Ville)
      v5: remove writes to nonexistent regs (Jesse)
          put RP and RC regs together (Jesse)
          fix RC6 enable (Jesse)
      v6: use correct fuse reads from NC (Jesse)
          split out min/max funcs for use in sysfs (Jesse)
          add debugfs & sysfs freq controls (Jesse)
      v7: update with Ben's hw_max changes (Jesse)
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6)
      [danvet: Follow checkpatch sugggestion to use min_t to avoid casting
      fun.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0a073b84
    • C
      drm/i915: Scale ring, rather than ia, frequency on Haswell · 3ebecd07
      Chris Wilson 提交于
      Haswell introduces a separate frequency domain for the ring (uncore). So
      where we used to increase the CPU (IA) clock with GPU busyness, we now
      need to scale the ring frequency directly instead. As the ring limits
      our memory bandwidth, it is vital for performance that when the GPU is
      busy, we increase the frequency of the ring to increase the available
      memory bandwidth.
      
      v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
      v3: s/max_ring_freq/min_ring_freq/ as that is what it is
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Add space checkpatch complained about.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3ebecd07
    • M
      drm/i915: shorten debugfs output simple attributes · 3a3b4f98
      Mika Kuoppala 提交于
      commit 647416f9
      Author: Kees Cook <keescook@chromium.org>
      Date:   Sun Mar 10 14:10:06 2013 -0700
      
          drm/i915: use simple attribute in debugfs routines
      
      made i915_next_seqno debugfs entry to crop it's output
      if returned value was large enough. Using simple_attr
      will limit the output to 24 bytes.
      
      Fix is to strip out preamples on all simple attributes
      that have one.
      
      v2: Fix all simple attributes (Daniel Vetter)
      
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3a3b4f98
    • B
      drm/i915: Better overclock support · 31c77388
      Ben Widawsky 提交于
      Most importantly this will allow users to set overclock frequencies in
      sysfs. Previously the max was limited by the RP0 max as opposed to the
      overclock max. This is useful if one wants to either limit the max
      overclock frequency, or set the minimum frequency to be in the overclock
      range. It also fixes an issue where if one sets the max frequency to be
      below the overclock max, they wouldn't be able to set back the proper
      overclock max.
      
      In addition I've added a couple of other bits:
      Show the overclock freq. as max in sysfs
      Print the overclock max in debugfs.
      Print a warning if the user sets the min frequency to be in the
      overclock range.
      
      In this patch I've decided to store the hw_max when we read it from the
      pcode at init. The reason I do this is the pcode reads can fail, and are
      slow.
      
      v2: Report when user requested overclocked max (Daniel)
      Remove when user sets min to overclock range (Daniel)
      
      Reported-by: freezer from #intel-gfx on irc
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      [danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
      that Mika spotted.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      31c77388
  7. 14 3月, 2013 2 次提交
  8. 05 3月, 2013 1 次提交
    • B
      drm/i915: Capture current context on error · 8c123e54
      Ben Widawsky 提交于
      On error, this represents the state of the currently running context at
      the time it was loaded.
      
      Unfortunately, since we're hung and can't switch out the context this
      may not tell us too much about the most current state of the context,
      but does give clues about what has happened since loading.
      
      Thanks to recent doc updates, we have a little more confidence regarding
      what is actually in this memory, and perhaps it will help us gain more
      insight into certain bugs. AFAICT, the most interesting info is in the
      first page. To save space, we only capture the first page. In the
      future, we might want to dump more.
      
      Sample of the relevant part of error state:
      render ring --- HW Context = 0x01b20000
      [0000] 00000000 1100105f 00002028 ffff0880
      [0010] 0000209c feff4040 000020c0 efdf0080
      [0020] 00002178 00000001 0000217c 00145855
      [0030] 00002310 00000000 00002314 00000000
      
      v2: Move error collection to the ring error code
      Change format of dump to not confuse intel_error_decode (Chris)
      Put the context error object with the others (Chris)
      Don't search bound_list instead of active_list (chris)
      
      v3: extract and flatten context recording (daniel)
      checkpatch related fixes for the copypasta in debugfs
      
      v4: bug in v3 (Daniel)
      -       if ((ring->id == RCS) && error->ccid)
      +       if ((ring->id != RCS) || !error->ccid)
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=55845
      Reviewed-by (v2): Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      [danvet: Bikeshed away the redudant parenthese around ring->id != RCS]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8c123e54
  9. 20 2月, 2013 2 次提交
  10. 31 1月, 2013 1 次提交
  11. 24 1月, 2013 1 次提交
  12. 21 1月, 2013 2 次提交
    • D
      drm/i915: dump refcount into framebuffer debugfs file · 623f9783
      Daniel Vetter 提交于
      Useful for checking whether the new refcounting works as advertised.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      623f9783
    • D
      drm: revamp locking around fb creation/destruction · 4b096ac1
      Daniel Vetter 提交于
      Well, at least step 1. The goal here is that framebuffer objects can
      survive outside of the mode_config lock, with just a reference held
      as protection. The first step to get there is to introduce a special
      fb_lock which protects fb lookup, creation and destruction, to make
      them appear atomic.
      
      This new fb_lock can nest within the mode_config lock. But the idea is
      (once the reference counting part is completed) that we only quickly
      take that fb_lock to lookup a framebuffer and grab a reference,
      without any other locks involved.
      
      vmwgfx is the only driver which does framebuffer lookups itself, also
      wrap those calls to drm_mode_object_find with the new lock.
      
      Also protect the fb_list walking in i915 and omapdrm with the new lock.
      
      As a slight complication there's also the list of user-created fbs
      attached to the file private. The problem now is that at fclose() time
      we need to walk that list, eventually do a modeset call to remove the
      fb from active usage (and are required to be able to take the
      mode_config lock), but in the end we need to grab the new fb_lock to
      remove the fb from the list. The easiest solution is to add another
      mutex to protect this per-file list.
      
      Currently that new fbs_lock nests within the modeset locks and so
      appears redudant. But later patches will switch around this sequence
      so that taking the modeset locks in the fb destruction path is
      optional in the fastpath. Ultimately the goal is that addfb and rmfb
      do not require the mode_config lock, since otherwise they have the
      potential to introduce stalls in the pageflip sequence of a compositor
      (if the compositor e.g. switches to a fullscreen client or if it
      enables a plane). But that requires a few more steps and hoops to jump
      through.
      
      Note that framebuffer creation/destruction is now double-protected -
      once by the fb_lock and in parts by the idr_lock. The later would be
      unnecessariy if framebuffers would have their own idr allocator. But
      that's material for another patch (series).
      
      v2: Properly initialize the fb->filp_head list in _init, otherwise the
      newly added WARN to check whether the fb isn't on a fpriv list any
      more will fail for driver-private objects.
      
      v3: Fixup two error-case unlock bugs spotted by Richard Wilbur.
      Reviewed-by: NRob Clark <rob@ti.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4b096ac1
  13. 20 1月, 2013 4 次提交
    • D
      drm/i915: clear up wedged transitions · 1f83fee0
      Daniel Vetter 提交于
      We have two important transitions of the wedged state in the current
      code:
      
      - 0 -> 1: This means a hang has been detected, and signals to everyone
        that they please get of any locks, so that the reset work item can
        do its job.
      
      - 1 -> 0: The reset handler has completed.
      
      Now the last transition mixes up two states: "Reset completed and
      successful" and "Reset failed". To distinguish these two we do some
      tricks with the reset completion, but I simply could not convince
      myself that this doesn't race under odd circumstances.
      
      Hence split this up, and add a new terminal state indicating that the
      hw is gone for good.
      
      Also add explicit #defines for both states, update comments.
      
      v2: Split out the reset handling bugfix for the throttle ioctl.
      
      v3: s/tmp/wedged/ sugested by Chris Wilson. Also fixup up a rebase
      error which prevented this patch from actually compiling.
      
      v4: To unify the wedged state with the reset counter, keep the
      reset-in-progress state just as a flag. The terminally-wedged state is
      now denoted with a big number.
      
      v5: Add a comment to the reset_counter special values explaining that
      WEDGED & RESET_IN_PROGRESS needs to be true for the code to be
      correct.
      
      v6: Fixup logic errors introduced with the wedged+reset_counter
      unification. Since WEDGED implies reset-in-progress (in a way we're
      terminally stuck in the dead-but-reset-not-completed state), we need
      ensure that we check for this everywhere. The specific bug was in
      wait_for_error, which would simply have timed out.
      
      v7: Extract an inline i915_reset_in_progress helper to make the code
      more readable. Also annote the reset-in-progress case with an
      unlikely, to help the compiler optimize the fastpath. Do the same for
      the terminally wedged case with i915_terminally_wedged.
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1f83fee0
    • D
      drm/i915: move wedged to the other gpu error handling stuff · 33196ded
      Daniel Vetter 提交于
      And to make Ben Widawsky happier, use the gpu_error instead of
      the entire device as the argument in some functions.
      
      Drop the outdated comment on ->wedged for now, a follow-up patch will
      change the semantics and add a proper comment again.
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      33196ded
    • D
      drm/i915: extract hangcheck/reset/error_state state into substruct · 99584db3
      Daniel Vetter 提交于
      This has been sprinkled all over the place in dev_priv. I think
      it'd be good to also move all the code into a separate file like
      i915_gem_error.c, but that's for another patch.
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      99584db3
    • B
      drm/i915: Remove use of gtt_mappable_entries · 93d18799
      Ben Widawsky 提交于
      Mappable_end, ie. size is almost always what you want as opposed to the
      number of entries. Since we already have that information, we can scrap
      the number of entries and only calculate it when needed.
      
      If gtt_start is !0, this will have slightly different behavior. This
      difference can only occur in DRI1, and exists when we try to kick out
      the firmware fb. The new code seems like a bugfix to me.
      
      The other case where we've changed the behavior is during init we check
      the mappable region against our current known upper and lower limits
      (64MB, and 512MB). This now matches the comment, and makes things more
      convenient after removing gtt_mappable_entries.
      
      Also worth noting is the setting of mappable_end is taken out of setup
      because we do it earlier now in the DRI2 case and therefore need to add
      that tiny hunk to support the DRI1 IOCTL.
      
      v2: Move up mappable end to before legacy AGP init
      
      v3: Add the dev_priv inclusion here from previous rebase error in patch
      5
      
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      [danvet: squash in fix for a printk format flag mismatch warning.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      93d18799
  14. 18 1月, 2013 3 次提交
  15. 15 1月, 2013 1 次提交
  16. 09 1月, 2013 1 次提交
  17. 19 12月, 2012 1 次提交
  18. 13 12月, 2012 1 次提交
    • D
      drm/i915: rework locking for intel_dpio|sbi_read|write · 09153000
      Daniel Vetter 提交于
      Spinning for up to 200 us with interrupts locked out is not good. So
      let's just spin (and even that seems to be excessive).
      
      And we don't call these functions from interrupt context, so this is
      not required. Besides that doing anything in interrupt contexts which
      might take a few hundred us is a no-go. So just convert the entire
      thing to a mutex. Also move the mutex-grabbing out of the read/write
      functions (add a WARN_ON(!is_locked)) instead) since all callers are
      nicely grouped together.
      
      Finally the real motivation for this change: Dont grab the modeset
      mutex in the dpio debugfs file, we don't need that consistency. And
      correctness of the dpio interface is ensured with the dpio_lock.
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      09153000
  19. 06 12月, 2012 3 次提交
  20. 04 12月, 2012 1 次提交
    • D
      drm/i915: fixup sparse warnings · 1a240d4d
      Daniel Vetter 提交于
      - __iomem where there is none (I love how we mix these things up).
      - Use gfp_t instead of an other plain type.
      - Unconfuse one place about enum pipe vs enum transcoder - for the pch
        transcoder we actually use the pipe enum. Fixup the other cases
        where we assign the pipe to the cpu transcoder with explicit casts.
      - Declare the mch_lock properly in a header.
      
      There is still a decent mess in intel_bios.c about __iomem, but heck,
      this is x86 and we're allowed to do that.
      
      Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk>
      [danvet: Use a space after the cast consistently and fix up the
      newly-added cast in i915_irq.c to properly use __iomem.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1a240d4d
  21. 01 12月, 2012 1 次提交
  22. 29 11月, 2012 2 次提交
  23. 12 11月, 2012 1 次提交