Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 9月, 2021 15 次提交
  3. 24 9月, 2021 1 次提交
    • 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
  5. 20 9月, 2021 1 次提交
  7. 08 9月, 2021 1 次提交
  9. 07 9月, 2021 6 次提交
  11. 31 8月, 2021 1 次提交
  13. 30 8月, 2021 1 次提交
  15. 25 8月, 2021 2 次提交
  17. 20 8月, 2021 1 次提交
  19. 05 8月, 2021 1 次提交
  21. 31 7月, 2021 2 次提交
  23. 30 7月, 2021 1 次提交
  25. 28 7月, 2021 1 次提交
  27. 27 7月, 2021 2 次提交
    • S
      drm/i915: Implement PSF GV point support · 192fbfb7
      由 Stanislav Lisovskiy 提交于 
      PSF GV points are an additional factor that can limit the
bandwidth available to display, separate from the traditional
QGV points.  Whereas traditional QGV points represent possible
memory clock frequencies, PSF GV points reflect possible
frequencies of the memory fabric.

Switching between PSF GV points has the advantage of incurring
almost no memory access block time and thus does not need to be
accounted for in watermark calculations.

This patch adds support for those on top of regular QGV points.
Those are supposed to be used simultaneously, i.e we are always
at some QGV and some PSF GV point, based on the current video
mode requirements.
Bspec: 64631, 53998

v2: Seems that initial assumption made during ml conversation
    was wrong, PCode rejects any masks containing points beyond
    the ones returned, so even though BSpec says we have around
    8 points theoretically, we can mask/unmask only those which
    are returned, trying to manipulate those beyond causes a
    failure from PCode. So switched back to generating mask
    from 1 - num_qgv_points, where num_qgv_points is the actual
    amount of points, advertised by PCode.

v3: - Extended restricted qgv point mask to 0xf, as we have now
      3:2 bits for PSF GV points(Matt Roper)
    - Replaced val2 with NULL from PCode request, since its not being
      used(Matt Roper)
    - Replaced %d to 0x%x for better readability(thanks for spotting)
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210531064845.4389-2-stanislav.lisovskiy@intel.com
      192fbfb7
    • M
      drm/i915: document caching related bits · 3821cc7f
      由 Matthew Auld 提交于 
      Try to document the object caching related bits, like cache_coherent and
cache_dirty.

v2(Ville):
 - As pointed out by Ville, fix the completely incorrect assumptions
   about the "partial" coherency on shared LLC platforms.
v3(Daniel):
 - Fix nonsense about "dirtying" the cache with reads.
v4(Daniel):
 - Various improvements, including adding some more details for WT.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210723105045.400841-1-matthew.auld@intel.com
      3821cc7f
  29. 23 7月, 2021 4 次提交