Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 23 11月, 2015 1 次提交
  3. 18 11月, 2015 6 次提交
  5. 16 11月, 2015 1 次提交
  7. 12 11月, 2015 3 次提交
  9. 10 11月, 2015 1 次提交
  11. 04 11月, 2015 1 次提交
  13. 02 11月, 2015 1 次提交
  15. 29 10月, 2015 2 次提交
  17. 26 10月, 2015 1 次提交
  19. 23 10月, 2015 1 次提交
  21. 22 10月, 2015 3 次提交
  23. 21 10月, 2015 3 次提交
  25. 13 10月, 2015 3 次提交
  27. 10 10月, 2015 1 次提交
  29. 09 10月, 2015 1 次提交
  31. 07 10月, 2015 3 次提交
  33. 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
  35. 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
  37. 30 9月, 2015 5 次提交
    • 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