1. 01 7月, 2013 4 次提交
    • D
      drm/i915: hw state readout for i9xx dplls · 8bcc2795
      Daniel Vetter 提交于
      In addition to existing stuff we also need to track DPLL_MD on gen4
      and vlv. This is prep work so that we can move the dpll enable
      sequence out from the ->mode_set callback into the crtc enabling
      functions.
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8bcc2795
    • D
      drm/i915: consolidate pch pll enable sequence · 15bdd4cf
      Daniel Vetter 提交于
      It's been splattered over 3 different places all doing random things.
      Now we have (mostly) the same sequence as i8xx/i9xx, but all called
      from the crtc_enable hook (through the pll->enable function):
      - write new dividers
      - enable vco and wait for stable clocks
      - write again for the pixel mutliplier
      
      I've left the seemingly random 200 usec delay in there, just in case.
      
      Also move the encoder->pre_pll_enable hook into the crtc_enable
      function, at the same spot we currently have a hack to enable the lvds
      port. Since that hack is now redundant, kill it.
      
      While doing this patch I've learned the hard way that we can only fire
      up the LVDS port if both the pch dpll _and_ the fdi rc pll are not yet
      enabled. Otherwise things go haywire, at least on cpt.
      
      v2: It is paramount to write the FPx divisors before we enable the
      the vco by writing to the DPLL registers, for otherwise the divisors
      won't get updated. This is in line with the i8xx/i9xx dpll.
      
      v3: To keep the nice abstraction add a ->mode_set callback to set the
      divisors. Also streamline the enabling/disabling code a bit by
      removing some cargo-cult duplication and clearing registers where
      possible in the ->disable hook.
      
      v4: Remove now unused local variable.
      Acked-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      15bdd4cf
    • D
      drm/i915: Fix reason for per-chip disabling of FBC · 8a5729a3
      Damien Lespiau 提交于
      When running on my snb machine, recent kernels display successively:
      
      [drm:intel_update_fbc], fbc set to per-chip default
      [drm:intel_update_fbc], fbc disabled per module param
      
      But no module param is set. This happens because the check for the
      module parameter uses a variable that has been overridden inside the
      "per-chip default" code.
      
      Fix up the logic and add another reason for the FBC to the be disabled.
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8a5729a3
    • D
      drm/i915: Introduce an HAS_IPS() macro · f5adf94e
      Damien Lespiau 提交于
      Follow the trend and don't code conditions with platforms but with
      features.
      Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f5adf94e
  2. 18 6月, 2013 1 次提交
  3. 13 6月, 2013 6 次提交
  4. 12 6月, 2013 1 次提交
  5. 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
  6. 06 6月, 2013 1 次提交
  7. 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
  8. 03 6月, 2013 2 次提交
  9. 01 6月, 2013 4 次提交
  10. 24 5月, 2013 3 次提交
  11. 23 5月, 2013 1 次提交
  12. 22 5月, 2013 1 次提交
  13. 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
  14. 11 5月, 2013 5 次提交
  15. 06 5月, 2013 1 次提交
  16. 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
  17. 30 4月, 2013 2 次提交