1. 22 12月, 2015 2 次提交
  2. 02 12月, 2015 1 次提交
  3. 19 11月, 2015 1 次提交
  4. 18 11月, 2015 1 次提交
  5. 13 10月, 2015 3 次提交
  6. 10 10月, 2015 1 次提交
  7. 09 10月, 2015 1 次提交
  8. 07 10月, 2015 3 次提交
  9. 06 10月, 2015 2 次提交
    • T
      drm/i915: Clean up associated VMAs on context destruction · e9f24d5f
      Tvrtko Ursulin 提交于
      Prevent leaking VMAs and PPGTT VMs when objects are imported
      via flink.
      
      Scenario is that any VMAs created by the importer will be left
      dangling after the importer exits, or destroys the PPGTT context
      with which they are associated.
      
      This is caused by object destruction not running when the
      importer closes the buffer object handle due the reference held
      by the exporter. This also leaks the VM since the VMA has a
      reference on it.
      
      In practice these leaks can be observed by stopping and starting
      the X server on a kernel with fbcon compiled in. Every time
      X server exits another VMA will be leaked against the fbcon's
      frame buffer object.
      
      Also on systems where flink buffer sharing is used extensively,
      like Android, this leak has even more serious consequences.
      
      This version is takes a general approach from the  earlier work
      by Rafael Barbalho (drm/i915: Clean-up PPGTT on context
      destruction) and tries to incorporate the subsequent discussion
      between Chris Wilson and Daniel Vetter.
      
      v2:
      
      Removed immediate cleanup on object retire - it was causing a
      recursive VMA unbind via i915_gem_object_wait_rendering. And
      it is in fact not even needed since by definition context
      cleanup worker runs only after the last context reference has
      been dropped, hence all VMAs against the VM belonging to the
      context are already on the inactive list.
      
      v3:
      
      Previous version could deadlock since VMA unbind waits on any
      rendering on an object to complete. Objects can be busy in a
      different VM which would mean that the cleanup loop would do
      the wait with the struct mutex held.
      
      This is an even simpler approach where we just unbind VMAs
      without waiting since we know all VMAs belonging to this VM
      are idle, and there is nothing in flight, at the point
      context destructor runs.
      
      v4:
      
      Double underscore prefix for __915_vma_unbind_no_wait and a
      commit message typo fix. (Michel Thierry)
      
      Note that this is just a partial/interim fix since we have a bit a
      fundamental issue with cleaning up, e.g.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=87729Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Testcase: igt/gem_ppgtt.c/flink-and-exit-vma-leak
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Rafael Barbalho <rafael.barbalho@intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      [danvet: Add a note that this isn't everything.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e9f24d5f
    • V
      drm/i915: Skip CHV PHY asserts until PHY has been fully reset · 3be60de9
      Ville Syrjälä 提交于
      The BIOS can leave the CHV display PHY in some odd state where
      some of the LDOs/lanes won't power down fully when unused. This
      will trigger a host of asserts that were added in:
      30142273 drm/i915: Add CHV PHY LDO power sanity checks
      6669e39f drm/i915: Add some CHV DPIO lane power state asserts
      
      To avoid that, skip the asserts until the PHY power well has been
      disabled at least once. That will fully reset the PHY, and once
      brought back up, the dynamic power down features will work correctly.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Deepak S<deepak.s@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3be60de9
  10. 02 10月, 2015 1 次提交
    • M
      drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset · 101b506a
      Michel Thierry 提交于
      There are some allocations that must be only referenced by 32-bit
      offsets. To limit the chances of having the first 4GB already full,
      objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
      DRM_MM_CREATE_TOP flags
      
      In specific, any resource used with flat/heapless (0x00000000-0xfffff000)
      General State Heap (GSH) or Instruction State Heap (ISH) must be in a
      32-bit range, because the General State Offset and Instruction State
      Offset are limited to 32-bits.
      
      Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if
      they can be allocated above the 32-bit address range. To limit the
      chances of having the first 4GB already full, objects will use
      DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible.
      
      The libdrm user of the EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag is here:
      http://lists.freedesktop.org/archives/intel-gfx/2015-September/075836.html
      
      v2: Changed flag logic from neeeds_32b, to supports_48b.
      v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel)
      v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK
      to use last PIN_ defined instead of hard-coded value; use correct limit
      check in eb_vma_misplaced. (Chris)
      v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris)
      v6: Apply pin-high for ggtt too (Chris)
      v7: Handle simultaneous pin-high and pin-mappable end correctly (Akash)
          Fix check for entries currently using +4GB addresses, use min_t and
          other polish in object_bind_to_vm (Chris)
      v8: Commit message updated to point to libdrm patch.
      v9: vmas are allocated in the correct ozone, so only check flag when the
          vma has not been allocated. (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
      Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      101b506a
  11. 30 9月, 2015 10 次提交
    • M
      drm/i915: Calculate watermark configuration during atomic check (v2) · 76305b1a
      Matt Roper 提交于
      v2: Don't forget to actually check the cstate->active value when
          tallying up the number of active CRTC's.  (Ander)
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      76305b1a
    • M
      drm/i915: Calculate ILK-style watermarks during atomic check (v3) · a28170f3
      Matt Roper 提交于
      Calculate pipe watermarks during atomic calculation phase, based on the
      contents of the atomic transaction's state structure.  We still program
      the watermarks at the same time we did before, but the computation now
      happens much earlier.
      
      While this patch isn't too exciting by itself, it paves the way for
      future patches.  The eventual goal (which will be realized in future
      patches in this series) is to calculate multiple sets up watermark
      values up front, and then program them at different times (pre- vs
      post-vblank) on the platforms that need a two-step watermark update.
      
      While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since
      this function only applies to ILK-style watermarks and we have a
      completely different function for SKL-style watermarks.
      
      Note that the original code had a memcmp() in ilk_update_wm() to avoid
      calling ilk_program_watermarks() if the watermarks hadn't changed.  This
      memcmp vanishes here, which means we may do some unnecessary result
      generation and merging in cases where watermarks didn't change, but the
      lower-level function ilk_write_wm_values already makes sure that we
      don't actually try to program the watermark registers again.
      
      v2: Squash a few commits from the original series together; no longer
          leave pre-calculated wm's in a separate temporary structure since
          it's easier to follow the logic if we just cut over to using the
          pre-calculated values directly.
      
      v3:
       - Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint
         and use intel_atomic_get_crtc_state() to avoid need for extra
         casting.  (Ander)
       - Drop unused intel_check_crtc() function prototype.  (Ander)
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a28170f3
    • M
      drm/i915: Drop intel_update_sprite_watermarks · 47c99438
      Matt Roper 提交于
      The only platform that still has an update_sprite_wm entrypoint is SKL;
      on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
      then performs a regular watermark update.  However intel_plane->wm is
      only used to update a couple fields in intel_wm_config, and those fields
      are never used by the SKL code, so on SKL an update_sprite_wm is
      effectively identical to an update_wm call.  Since we're already
      ensuring that the regular intel_update_wm is called any time we'd try to
      call intel_update_sprite_watermarks, the whole call is redundant and can
      be dropped.
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      47c99438
    • M
      drm/i915/skl: Simplify wm structures slightly (v2) · 4969d33e
      Matt Roper 提交于
      A bunch of SKL watermark-related structures have the cursor plane as a
      separate entry from the rest of the planes.  Since a previous patch
      updated I915_MAX_PLANES such that those plane arrays now have a slot for
      the cursor, update the code to use the new slot in the existing plane
      arrays and kill off the cursor-specific structures.
      
      There shouldn't be any functional change here; this is just shuffling
      around how the data is stored in some of the data structures.  The whole
      patch is generated with Coccinelle via the following semantic patch:
      
              @@ struct skl_pipe_wm_parameters WMP; @@
              - WMP.cursor
              + WMP.plane[PLANE_CURSOR]
      
              @@ struct skl_pipe_wm_parameters *WMP; @@
              - WMP->cursor
              + WMP->plane[PLANE_CURSOR]
      
              @@ @@
              struct skl_pipe_wm_parameters {
              ...
              - struct intel_plane_wm_parameters cursor;
              ...
              };
      
              @@
              struct skl_ddb_allocation DDB;
              expression E;
              @@
              - DDB.cursor[E]
              + DDB.plane[E][PLANE_CURSOR]
      
              @@
              struct skl_ddb_allocation *DDB;
              expression E;
              @@
              - DDB->cursor[E]
              + DDB->plane[E][PLANE_CURSOR]
      
              @@ @@
              struct skl_ddb_allocation {
              ...
              - struct skl_ddb_entry cursor[I915_MAX_PIPES];
              ...
              };
      
              @@
              struct skl_wm_values WMV;
              expression E1, E2;
              @@
              (
              - WMV.cursor[E1][E2]
              + WMV.plane[E1][PLANE_CURSOR][E2]
              |
              - WMV.cursor_trans[E1]
              + WMV.plane_trans[E1][PLANE_CURSOR]
              )
      
              @@
              struct skl_wm_values *WMV;
              expression E1, E2;
              @@
              (
              - WMV->cursor[E1][E2]
              + WMV->plane[E1][PLANE_CURSOR][E2]
              |
              - WMV->cursor_trans[E1]
              + WMV->plane_trans[E1][PLANE_CURSOR]
              )
      
              @@ @@
              struct skl_wm_values {
              ...
              - uint32_t cursor[I915_MAX_PIPES][8];
              ...
              - uint32_t cursor_trans[I915_MAX_PIPES];
              ...
              };
      
              @@ struct skl_wm_level WML; @@
              (
              - WML.cursor_en
              + WML.plane_en[PLANE_CURSOR]
              |
              - WML.cursor_res_b
              + WML.plane_res_b[PLANE_CURSOR]
              |
              - WML.cursor_res_l
              + WML.plane_res_l[PLANE_CURSOR]
              )
      
              @@ struct skl_wm_level *WML; @@
              (
              - WML->cursor_en
              + WML->plane_en[PLANE_CURSOR]
              |
              - WML->cursor_res_b
              + WML->plane_res_b[PLANE_CURSOR]
              |
              - WML->cursor_res_l
              + WML->plane_res_l[PLANE_CURSOR]
              )
      
              @@ @@
              struct skl_wm_level {
              ...
              - bool cursor_en;
              ...
              - uint16_t cursor_res_b;
              - uint8_t cursor_res_l;
              ...
              };
      
      v2: Use a PLANE_CURSOR enum entry rather than making the code reference
          I915_MAX_PLANES or I915_MAX_PLANES+1, which was confusing.  (Ander)
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4969d33e
    • M
      drm/i915: Determine I915_MAX_PLANES from plane enum · 31409e97
      Matt Roper 提交于
      Let the compiler figure out what I915_MAX_PLANES is from 'enum plane' so
      that we don't need a separate #define.
      
      While we're at it, add the cursor plane to the enum.  This will cause
      I915_MAX_PLANES to now include the cursor plane in its count (it didn't
      previously).   This change is safe since we currently only use this
      value in array declarations (never in the actual code logic); we just
      wind up allocating slightly more memory than we need to.  A followup
      patch will cause various parts of the code to start using the extra
      array element where appropriate.
      
      (This patch probably should have been squashed with the followup patch,
      but I couldn't figure out how to get Coccinelle to modify enum
      declarations...)
      Suggested-by: NAnder Conselvan De Oliveira <conselvan2@gmail.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      31409e97
    • D
      drm/i915: Remove setparam ioctl · c668cde5
      Daniel Vetter 提交于
      This was only used for the ums+gem combo, so ripe for removal now that
      we only have kms code left.
      
      v2: Drop fence_reg_start since it's now unused, noticed by Ville.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c668cde5
    • J
      drm/i915: make backlight hooks connector specific · 5507faeb
      Jani Nikula 提交于
      Previously we've relied on having basically one backlight and one
      backlight type per platform. This is already a bit quirky with PMIC PWM
      support on VLV/CHV platforms with MIPI DSI. In the foreseeable future
      we'll have at least DPCD based backlight control on eDP and DCS command
      based backlight control on MIPI DSI. Backlight is becoming more and more
      connector specific, so reflect this fact by making the backlight control
      hooks connector specific.
      
      This enables further work to reuse generic backlight code in
      intel_panel.c while adding more specific backlight code accessed via the
      hooks.
      
      Cc: Deepak M <m.deepak@intel.com>
      Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Reviewed-by: NDeepak M <m.deepak@intel.com>
      Reviewed-by: NYetunde Adebisi <yetundex.adebisi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5507faeb
    • V
      drm/i915: Read czclk from CCK on vlv/chv · bfa7df01
      Ville Syrjälä 提交于
      As with the cdclk, read out czclk from CCK as well. This gives us the
      real current value and avoids having to decode fuses and whatnot.
      
      Also store it in kHz under dev_priv like we do for cdlck since it's not
      just an rps related clock, and having it in kHz is more
      standard/convenient for some things.
      
      Imre also pointed out that we currently fail to read czclk on VLV, which
      means the PFI credit programming isn't working as expected.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bfa7df01
    • V
      drm/i915: s/mode/adjusted_mode/ in functions that really get passed the adjusted_mode · 5e7234c9
      Ville Syrjälä 提交于
      Rename the function argument to 'adjusted_mode' whenever the function
      only ever gets passed the adjusted_mode.
      
      v2: Update due to intel_dsi.c changes
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NMika Kahola <mika.kahola@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5e7234c9
    • R
      drm/i915: Detect virtual south bridge · 30c964a6
      Robert Beckett 提交于
      Virtualized systems often use a virtual P2X4 south bridge.
      Detect this in intel_detect_pch and make a best guess as to which PCH
      we should be using.
      
      This was seen on vmware esxi hypervisor. When passing the graphics device
      through to a guest, it can not pass through the PCH. Instead it simulates
      a P2X4 southbridge.
      Signed-off-by: NRobert Beckett <robert.beckett@intel.com>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      30c964a6
  12. 28 9月, 2015 1 次提交
  13. 25 9月, 2015 1 次提交
  14. 23 9月, 2015 9 次提交
  15. 15 9月, 2015 1 次提交
  16. 14 9月, 2015 2 次提交
    • N
      drm/i915: Split alloc from init for lrc · e84fe803
      Nick Hoath 提交于
      Extend init/init_hw split to context init.
         - Move context initialisation in to i915_gem_init_hw
         - Move one off initialisation for render ring to
              i915_gem_validate_context
         - Move default context initialisation to logical_ring_init
      
      Rename intel_lr_context_deferred_create to
      intel_lr_context_deferred_alloc, to reflect reduced functionality &
      alloc/init split.
      
      This patch is intended to split out the allocation of resources &
      initialisation to allow easier reuse of code for resume/gpu reset.
      
      v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
          Left ->init_context int intel_lr_context_deferred_alloc
          (Daniel Vetter)
          Remove unnecessary init flag & ring type test. (Daniel Vetter)
          Improve commit message (Daniel Vetter)
      v3: On init/reinit, set the hw next sequence number to the sw next
          sequence number. This is set to 1 at driver load time. This prevents
          the seqno being reset on reinit (Chris Wilson)
      v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
          on reset.
          This makes it obvious which bbs are which after a reset. (David Gordon
          & John Harrison)
          Rebase.
      v5: Rebase. Fixed rebase breakage. Put context pinning in separate
          function. Removed code churn. (Thomas Daniel)
      v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)
      
      Issue: VIZ-4798
      Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: John Harrison <john.c.harrison@intel.com>
      Cc: David Gordon <david.s.gordon@intel.com>
      Cc: Thomas Daniel <thomas.daniel@intel.com>
      Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e84fe803
    • M
      drm/i915: skip modeset if compatible for everyone. · 6764e9f8
      Maarten Lankhorst 提交于
      This is done as a separate commit, to make it easier to revert
      when things break.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6764e9f8