1. 21 7月, 2013 1 次提交
    • D
      drm/i915: fix up gt init sequence fallout · 181d1b9e
      Daniel Vetter 提交于
      The regression fix for gen6+ rps fallout
      
      commit 7dcd2677
      Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Date:   Wed Jul 17 10:22:58 2013 +0400
      
          drm/i915: fix long-standing SNB regression in power consumption after resume
      
      unintentionally also changed the init sequence ordering between
      gt_init and gt_reset - we need to reset BIOS damage like leftover
      forcewake references before we run our own code. Otherwise we can get
      nasty dmesg noise like
      
      [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
      
      again. Since _reset suggests that we first need to have stuff
      initialized (which isn't the case here) call it sanitze instead.
      
      While at it also block out the rps disable introduced by the above
      commit on ilk: We don't have any knowledge of ilk rps being broken in
      similar ways. And the disable functions uses the default hw state
      which is only read out when we're enabling rps. So essentially we've
      been writing random grabage into that register.
      Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: stable@vger.kernel.org
      Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      181d1b9e
  2. 20 7月, 2013 1 次提交
  3. 01 7月, 2013 1 次提交
  4. 18 6月, 2013 1 次提交
  5. 16 6月, 2013 1 次提交
    • C
      drm/i915: Restore fences after resume and GPU resets · 19b2dbde
      Chris Wilson 提交于
      Stéphane Marchesin found that fences for pinned objects (i.e. the
      scanout) were not being restored upon resume, leading to corruption on
      the display and reference counting issues. This is due to a bug in
      
      commit 312817a3 [2.6.38]
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Mon Nov 22 11:50:11 2010 +0000
      
          drm/i915: Only save and restore fences for UMS
      
      that zapped the pinned fences even though they were in use.
      Fortuitously, whilst we forced a VT switch during suspend and resume,
      no fences were ever pinned at the time. However, we now can do
      switchless S3 transitions and so the old bug finally surfaces.
      Reported-by: NStéphane Marchesin <marcheu@chromium.org>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Stéphane Marchesin <marcheu@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      19b2dbde
  6. 13 6月, 2013 6 次提交
  7. 12 6月, 2013 1 次提交
  8. 11 6月, 2013 5 次提交
    • D
      drm/i915: enable/disable hooks for shared dplls · e7b903d2
      Daniel Vetter 提交于
      Looks at first like a bit of overkill, but
      - Haswell actually wants different enable/disable functions for
        different plls.
      - And once we have full dpll hw state tracking we can move the full
        register setup into the ->enable hook.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e7b903d2
    • D
      drm/i915: scrap register address storage · e9a632a5
      Daniel Vetter 提交于
      Using ids in register macros is much more common in our driver. Also
      this way we can reduce the platform specific stuff a bit.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e9a632a5
    • D
      drm/i915: metadata for shared dplls · 46edb027
      Daniel Vetter 提交于
      An id to match the idx (useful for register access macros) and a name
      fore neater debug output.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      46edb027
    • D
      drm/i915: switch crtc->shared_dpll from a pointer to an enum · e2b78267
      Daniel Vetter 提交于
      Dealing with discrete enum values is simpler for hw state readout and
      pipe config computations than pointers - having neat names instead of
      chasing pointers should look better in the code.
      
      This isn't a that good reason for pch plls, but on haswell we actually
      have 3 different types of plls: WRPLL, SPLL and the DP clocks. Having
      explicit names should help there.
      
      Since this also adds the intel_crtc_to_shared_dpll helper to further
      abstract away the crtc -> dpll relationship this will also help to
      make the next patch simpler, which moves the shared dpll into the pipe
      configuration.
      
      Also note that for uniformity we have two special dpll ids: NONE for
      pipes which need a shared pll but don't have one (yet) and private for
      when there's a non-shared pll (e.g. per-pipe or per-port pll).
      
      I've thought whether we should also add a 2nd enum for the type of the
      pll we want (for really generic pll selection code) but thrown that
      idea out again - likely there's too much platform craziness going on
      to be able to share the pll selection logic much.
      
      Since this touched all the shared_pll functions a bit I've also done
      an s/intel_crtc/crtc/ replacement on a few of them.
      
      v2: Kill DPLL_ID_NONE. It's probably better to call it DPLL_ID_INVALID and use
      it to check that the compute config stage assigns a dpll to every pipe.
      But since that code isn't ready yet until we move the dpll selection out
      of the ->mode_set callback, there's no use for it.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e2b78267
    • D
      drm/i915: s/pch_pll/shared_dpll/ · e72f9fbf
      Daniel Vetter 提交于
      For fastboot we need some support to read out the sharing state of
      plls, at least for platforms where they can be shared (or freely
      assigned at least). Now for ivb we already have pretty extensive
      infrastructure for tracking pch plls, and it took us an aweful lot of
      tries to get that remotely right. Note that hsw could also share plls,
      but even now they're already freely assignable. So we need this on
      more than just ivb.
      
      So on top of the usual fastboot fun pll sharing seems to be an
      additional step up in fragility. Hence a common infrastructure for all
      shared/freely assignable display plls seems to be in order.
      
      The plan is to have a bit of dpll hw state readout code, which can be
      used individually, but also to fill in the pipe config. The hw state
      cross check code will then use that information to make sure that
      after every modeset every pipe still is connected to a pll which still
      has the correct configuration - a lot of the pch pll sharing bugs
      where due to incorrect sharing.
      
      We start this endeavour with a simple s/pch_pll/shared_dpll/ rename
      job.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e72f9fbf
  9. 06 6月, 2013 1 次提交
  10. 04 6月, 2013 1 次提交
    • D
      drm/i915: move find_pll callback to dev_priv->display · ee9300bb
      Daniel Vetter 提交于
      Now that the DP madness is cleared out, this is all only per-platform.
      So move it out from the intel clock limits structure.
      
      While at it drop the intel prefix on the static functions, call the
      vtable entry find_dpll (since it's for the display pll) and rip out
      the now unnecessary forward declarations.
      
      Note that the parameters of ->find_dpll are still unchanged, but they
      eventually need to be moved over to just take in a pipe configuration.
      But currently a lot of things are still missing from the pipe
      configuration (reflock, output-specific dpll limits and preferences,
      downclocked dotclock). So this will happen in a later step.
      
      Note that intel_g4x_limit has a peculiar case where it selects
      intel_limits_i9xx_sdvo as the limit. This is pretty bogus and also not
      used since the only output types left are DP and native TV-out which
      both use special pre-tuned dpll values.
      
      v2: Re-add comment for the find_pll callback (requested by Paulo) and
      elaborate on why the transformation is correct for g4x platforms (to
      clarify a review question from Paulo). Double up on that by adding a
      WARN as suggested by Paulo Zanoni on irc.
      
      v3: Initialize limits to NULL since gcc is now unhappy.
      
      v4: v2/3 will blow up with a NULL dereference in ->find_dpll for dp and
      TV-out ports, spotted by Paulo on irc. So just give up on this madness for
      now, and leave this to be fixed in a later patch.
      
      v5: Since the ever-so-slight change for g4x might result in some dpll
      parameter computation failing spuriously where before it didn't for
      ports with preset dpll settings (DP & TV-out) override this. For
      paranoia also do it in the ilk+ code.
      
      Cc: Paulo Zanoni <przanoni@gmail.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ee9300bb
  11. 03 6月, 2013 2 次提交
  12. 01 6月, 2013 4 次提交
  13. 24 5月, 2013 3 次提交
  14. 23 5月, 2013 1 次提交
  15. 22 5月, 2013 1 次提交
  16. 21 5月, 2013 1 次提交
    • P
      drm/i915: remove intel_update_linetime_watermarks · 1011d8c4
      Paulo Zanoni 提交于
      The spec says the linetime watermarks must be programmed before
      enabling any display low power watermarks, but we're currently
      updating the linetime watermarks after we call intel_update_watermarks
      (and only at crtc_mode_set, not at crtc_{enable,disable}). So IMHO the
      best way guarantee the linetime watermarks will be updated before the
      low power watermarks is inside the update_wm function, because it's
      the function that enables low power watermarks. And since Haswell is
      the only platform that has linetime watermarks, let's completely kill
      the "intel_update_linetime_watermarks" abstraction and just use the
      intel_update_watermarks abstraction by creating haswell_update_wm.
      
      For now haswell_update_wm is still calling sandybridge_update_wm, but
      in the future I plan to implement a function specific to Haswell.
      
      v2: - Rename patch
          - Disable LP watermarks before changing linetime WMs (Chris)
          - Add a comment explaining that this is just temporary code.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1011d8c4
  17. 11 5月, 2013 5 次提交
  18. 06 5月, 2013 1 次提交
  19. 01 5月, 2013 1 次提交
    • M
      drm/i915: reference count for i915_hw_contexts · dce3271b
      Mika Kuoppala 提交于
      Enabling PPGTT and also the need to track which context was guilty of
      gpu hang (arb robustness enabling) have put pressure for struct i915_hw_context
      to be more than just a placeholder for hw context state.
      
      In order to track object lifetime properly in a multi peer usage, add reference
      counting for i915_hw_context.
      
      v2: track i915_hw_context pointers instead of using ctx_ids
      (from Chris Wilson)
      
      v3 (Ben): Get rid of do_release() and handle refcounting more compactly.
      (recommended by Chis)
      
      v4: kref_* put inside static inlines (Daniel Vetter)
      remove code duplication on freeing context (Chris Wilson)
      
      v5: idr_remove and ctx->file_priv = NULL in destroy ioctl (Chris)
      This actually will cause a problem if one destroys a context and later
      refers to the idea of the context (multiple contexts may have the same
      id, but only 1 will exist in the idr).
      
      v6: Strip out the request related stuff. Reworded commit message.
      Got rid of do_destroy and introduced i915_gem_context_release_handle,
      suggested by Chris Wilson.
      
      v7: idr_remove can't be called inside idr_for_each (Chris Wilson)
      
      Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v5)
      Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v7)
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Squash sob lines, the patch ping-ponged between Ben and Mika
      a bit ...]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      dce3271b
  20. 30 4月, 2013 2 次提交