Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 12月, 2021 1 次提交
  3. 20 12月, 2021 1 次提交
  5. 18 12月, 2021 3 次提交
  7. 10 12月, 2021 1 次提交
  9. 01 12月, 2021 1 次提交
    • T
      drm/i915: Use per device iommu check · cca08469
      由 Tvrtko Ursulin 提交于 
      With both integrated and discrete Intel GPUs in a system, the current
global check of intel_iommu_gfx_mapped, as done from intel_vtd_active()
may not be completely accurate.

In this patch we add i915 parameter to intel_vtd_active() in order to
prepare it for multiple GPUs and we also change the check away from Intel
specific intel_iommu_gfx_mapped (global exported by the Intel IOMMU
driver) to probing the presence of IOMMU on a specific device using
device_iommu_mapped().

This will return true both for IOMMU pass-through and address translation
modes which matches the current behaviour. If in the future we wanted to
distinguish between these two modes we could either use
iommu_get_domain_for_dev() and check for __IOMMU_DOMAIN_PAGING bit
indicating address translation, or ask for a new API to be exported from
the IOMMU core code.

v2:
  * Check for dmar translation specifically, not just iommu domain. (Baolu)

v3:
 * Go back to plain "any domain" check for now, rewrite commit message.

v4:
 * Use device_iommu_mapped. (Robin, Baolu)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Acked-by: NRobin Murphy <robin.murphy@arm.com>
Reviewed-by: NLu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211126141424.493753-1-tvrtko.ursulin@linux.intel.com
      cca08469
  11. 20 11月, 2021 2 次提交
  13. 03 11月, 2021 3 次提交
  15. 29 10月, 2021 1 次提交
  17. 05 10月, 2021 1 次提交
  19. 29 9月, 2021 20 次提交
  21. 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
  23. 20 9月, 2021 2 次提交
  25. 08 9月, 2021 1 次提交
  27. 07 9月, 2021 2 次提交