Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 11月, 2021 13 次提交
  3. 03 11月, 2021 1 次提交
  5. 01 10月, 2021 1 次提交
    • J
      drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch enabled · ef39826c
      由 José Roberto de Souza 提交于 
      Legacy cursor APIs are handled by intel_legacy_cursor_update(), that
calls drm_atomic_helper_update_plane() when going through the
slow/atomic path to update cursor, what was the case for PSR2
selective fetch.

drm_atomic_helper_update_plane() sets
drm_atomic_state->legacy_cursor_update to true when updating the
cursor plane, to allow several cursor updates to happen within the
same frame, as userspace does that.
If drivers waited for a vblank increment at the end of every cursor
movement that would cause a visible lag in the cursor.

But this optimization do not properly work with PSR2 selective fetch
dirt area calculation, for example if within a single frame the cursor
had 3 moves the final dirt area programmed to PSR2_MAN_TRK_CTL would
be based in the second movement as old state and third movement as new
state, not updating the area where cursor was in the first state.

So here switching back to the fast path approach in
intel_legacy_cursor_update() and handling cursor movements as
frontbuffer rendering(psr_force_hw_tracking_exit()), that is not the
most optimal for power-savings but is the solution that we have until
mailbox style updates is implemented.

Also removing the cursor workaround as not it is properly undestand
the issue and is know that it will never cover all the cases.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-5-jose.souza@intel.com
      ef39826c
  7. 30 9月, 2021 1 次提交
  9. 24 9月, 2021 4 次提交
    • V
      drm/i915/fbc: Allow higher compression limits on FBC1 · 09bbdd87
      由 Ville Syrjälä 提交于 
      On FBC1 we can specify an arbitrary cfb stride. The hw will
simply throw away any compressed line that would exceed the
specified limit and keep using the uncompressed data instead.
Thus we can allow arbitrary compression limits.

The one thing we have to keep in mind though is that the cfb
stride is specified in units of 32B (gen2) or 64B (gen3+).
Fortunately X-tile is already 128B (gen2) or 512B (gen3+) wide
so as long as we limit outselves to the same 4x compression
limit that FBC2 has we are guaranteed to have a sufficiently
aligned cfb stride.
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210921152517.803-5-ville.syrjala@linux.intel.com
      09bbdd87
    • V
      drm/i915/fbc: Implement Wa_16011863758 for icl+ · 5f524aea
      由 Ville Syrjälä 提交于 
      There's some kind of weird corner cases in FBC which requires
FBC segments to be separated by at least one extra cacheline.
Make sure that is present.

v2: Respin to fit in with skl_fbc_min_cfb_stride()
v3: Make it build

Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> #v1
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210921181245.15091-1-ville.syrjala@linux.intel.com
      5f524aea
    • V
      drm/i915/fbc: Align FBC segments to 512B on glk+ · 2f051f67
      由 Ville Syrjälä 提交于 
      Apply the same 512 byte FBC segment alignment to glk+ as we use
on skl+. The only real difference is that we now have a dedicated
register for the FBC override stride. Not 100% sure which
platforms really need the 512B alignment, but it's easiest
to just do it on everything.

Also the hardware no longer seems to misclaculate the CFB stride
for linear, so we can omit the use of the override stride for
linear unless the stride is misaligned.
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210921152517.803-3-ville.syrjala@linux.intel.com
      2f051f67
    • V
      drm/i915/fbc: Rework cfb stride/size calculations · bdc1a2d2
      由 Ville Syrjälä 提交于 
      The code to calculate the cfb stride/size is a bit of mess.
The cfb size is getting calculated based purely on the plane
stride and plane height. That doesn't account for extra
alignment we want for the cfb stride. The gen9 override
stride OTOH is just calculated based on the plane width, and
it does try to make things more aligned but any extra alignment
added there is not considered in the cfb size calculations.
So not at all convinced this is working as intended. Additionally
the compression limit handling is split between the cfb allocation
code and g4x_dpfc_ctl_limit() (for the 16bpp case), which is just
confusing.

Let's streamline the whole thing:
- Start with the plane stride, convert that into cfb stride (cfb is
  always 4 bytes per pixel). All the calculations will assume 1:1
  compression limit since that will give us the max values, and we
  don't yet know how much stolen memory we will be able to allocate
- Align the cfb stride to 512 bytes on modern platforms. This guarantees
  the 4 line segment will be 512 byte aligned regardles of the final
  compression limit we choose later. The 512 byte alignment for the
  segment is required by at least some of the platforms, and just doing
  it always seems like the easiest option
- Figure out if we need to use the override stride or not. For X-tiled
  it's never needed since the plane stride is already 512 byte aligned,
  for Y-tiled it will be needed if the plane stride is not a multiple
  of 512 bytes, and for linear it's apparently always needed because the
  hardware miscalculates the cfb stride as PLANE_STRIDE*512 instead of
  the PLANE_STRIDE*64 that it use with linear.
- The cfb size will be calculated based on the aligned cfb stride to
  guarantee we actually reserved enough stolen memory and the FBC hw
  won't end up scribbling over whatever else is allocated in stolen
- The compression limit handling we just do fully in the cfb allocation
  code to make things less confusing

v2: Write the min cfb segment stride calculation in a more
    explicit way to make it clear what is going on
v3: Remeber to update fbc->limit when changing to 16bpp

Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v2
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210923042151.19052-1-ville.syrjala@linux.intel.com
      bdc1a2d2
  11. 20 8月, 2021 4 次提交
  13. 17 8月, 2021 1 次提交
  15. 21 7月, 2021 1 次提交
  17. 02 7月, 2021 1 次提交
  19. 25 6月, 2021 9 次提交
  21. 07 5月, 2021 1 次提交
  23. 06 5月, 2021 1 次提交
  25. 26 4月, 2021 1 次提交
  27. 14 4月, 2021 1 次提交
    • L
      drm/i915/display: rename display version macros · 93e7e61e
      由 Lucas De Marchi 提交于 
      While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:

	1) Why is the == comparison special that deserves a separate
	macro instead of just getting the version and comparing directly
	like is done for >, >=, <=?

	2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
	brevity. If we remove the current users of IS_DISPLAY_VER(), we
	could actually repurpose it for a range check

With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.

So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:

	@@ expression dev_priv, E1; @@
	- !IS_DISPLAY_VER(dev_priv, E1)
	+ DISPLAY_VER(dev_priv) != E1

	@@ expression dev_priv, E1; @@
	- IS_DISPLAY_VER(dev_priv, E1)
	+ DISPLAY_VER(dev_priv) == E1

	@@ expression dev_priv, from, until; @@
	- IS_DISPLAY_RANGE(dev_priv, from, until)
	+ IS_DISPLAY_VER(dev_priv, from, until)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
      93e7e61e