[Intel-gfx] [PATCH v3 4/8] drm/i915: ppgtt update pvmmio optimization
This patch extends g2v notification to notify host GVT-g of
ppgtt update from guest, including alloc_4lvl, clear_4lv4 and
insert_4lvl. It uses shared page to pass the additional params.
This patch also add one new pvmmio level to control ppgtt update.
Use PVMMIO_PPGTT_UPDATE to control this level of pvmmio optimization.
v0: RFC
v1: rebase
v2: added pv callbacks for vm.{allocate_va_range, insert_entries,
clear_range} within ppgtt.
v3: rebase, disable huge page ppgtt support when using PVMMIO ppgtt
update due to complex and performance impact.
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: He Min
Cc: Jiang Fei
Cc: Gong Zhipeng
Cc: Yuan Hang
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_gem.c | 3 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 67 +
drivers/gpu/drm/i915/i915_pvinfo.h | 3 ++
drivers/gpu/drm/i915/i915_vgpu.c| 2 +-
4 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 93d0928..beb3f70 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5496,7 +5496,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
int ret;
/* We need to fallback to 4K pages if host doesn't support huge gtt. */
- if (intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
+ if ((intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
+ || PVMMIO_LEVEL_ENABLE(dev_priv, PVMMIO_PPGTT_UPDATE))
mkwrite_device_info(dev_priv)->page_sizes =
I915_GTT_PAGE_SIZE_4K;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 29ca900..84039ef 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -956,6 +956,25 @@ static void gen8_ppgtt_clear_4lvl(struct
i915_address_space *vm,
}
}
+static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm,
+ u64 start, u64 length)
+{
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+ struct i915_pml4 *pml4 = &ppgtt->pml4;
+ struct drm_i915_private *dev_priv = vm->i915;
+ struct pv_ppgtt_update *pv_ppgtt =
+ &dev_priv->vgpu.shared_page->pv_ppgtt;
+ u64 orig_start = start;
+ u64 orig_length = length;
+
+ gen8_ppgtt_clear_4lvl(vm, start, length);
+
+ pv_ppgtt->pdp = px_dma(pml4);
+ pv_ppgtt->start = orig_start;
+ pv_ppgtt->length = orig_length;
+ I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_CLEAR);
+}
+
static inline struct sgt_dma {
struct scatterlist *sg;
dma_addr_t dma, max;
@@ -1197,6 +1216,25 @@ static void gen8_ppgtt_insert_4lvl(struct
i915_address_space *vm,
}
}
+static void gen8_ppgtt_insert_4lvl_pv(struct i915_address_space *vm,
+ struct i915_vma *vma,
+ enum i915_cache_level cache_level,
+ u32 flags)
+{
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+ struct drm_i915_private *dev_priv = vm->i915;
+ struct pv_ppgtt_update *pv_ppgtt =
+ &dev_priv->vgpu.shared_page->pv_ppgtt;
+
+ gen8_ppgtt_insert_4lvl(vm, vma, cache_level, flags);
+
+ pv_ppgtt->pdp = px_dma(&ppgtt->pml4);
+ pv_ppgtt->start = vma->node.start;
+ pv_ppgtt->length = vma->node.size;
+ pv_ppgtt->cache_level = cache_level;
+ I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_INSERT);
+}
+
static void gen8_free_page_tables(struct i915_address_space *vm,
struct i915_page_directory *pd)
{
@@ -1466,6 +1504,30 @@ static int gen8_ppgtt_alloc_4lvl(struct
i915_address_space *vm,
return -ENOMEM;
}
+static int gen8_ppgtt_alloc_4lvl_pv(struct i915_address_space *vm,
+u64 start, u64 length)
+{
+ struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+ struct i915_pml4 *pml4 = &ppgtt->pml4;
+ struct drm_i915_private *dev_priv = vm->i915;
+ struct pv_ppgtt_update *pv_ppgtt =
+ &dev_priv->vgpu.shared_page->pv_ppgtt;
+ int ret;
+ u64 orig_start = start;
+ u64 orig_length = length;
+
+ ret = gen8_ppgtt_alloc_4lvl(vm, start, length);
+ if (ret)
+ return ret;
+
+ pv_ppgtt->pdp = px_dma(pml4);
+ pv_ppgtt->start = orig_start;
+ pv_ppgtt->length = orig_length;
+ I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_ALLOC);
+
+ return 0;
+}
+
static void gen8_dump_pdp(struct i915_hw_ppgtt *ppgtt,
struct i915_page_directory_pointer *pdp,
u64 start, u64 length,
@@ -1631,6 +1693,11 @@ static struct i915_hw_ppgtt *gen8_ppgtt_create(struct
drm_i915_private
[Intel-gfx] [PATCH v3 1/8] drm/i915: introduced pv capability for vgpu
both u32 pv_caps field and pvmmio_caps are used to control the different
level pvmmio feature for MMIO emulation in both guest and GVT.
These fields are default zero, no pvmmio feature enabled.
it also adds VGT_CAPS_PVMMIO capability BIT for guest to check GVTg
can support PV feature or not.
v0: RFC, introudced enable_pvmmio module parameter.
v1: addressed RFC comment to remove enable_pvmmio module parameter
by pv capability check.
v2: rebase
v3: distinct pv caps from guest and host. renamed enable_pvmmio to
pvmmio_caps which is used for host pv caps.
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: He Min
Cc: Jiang Fei
Cc: Gong Zhipeng
Cc: Yuan Hang
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_drv.h| 11 +++
drivers/gpu/drm/i915/i915_pvinfo.h | 16 +++-
drivers/gpu/drm/i915/i915_vgpu.c | 23 +--
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3017ef0..7b2d7cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,6 +56,7 @@
#include "i915_params.h"
#include "i915_reg.h"
+#include "i915_pvinfo.h"
#include "i915_utils.h"
#include "intel_bios.h"
@@ -1343,6 +1344,7 @@ struct i915_workarounds {
struct i915_virtual_gpu {
bool active;
u32 caps;
+ u32 pv_caps;
};
/* used in computing the new watermarks state */
@@ -2853,6 +2855,11 @@ static inline bool intel_vgpu_active(struct
drm_i915_private *dev_priv)
return dev_priv->vgpu.active;
}
+static inline bool intel_vgpu_has_pvmmio(struct drm_i915_private *dev_priv)
+{
+ return dev_priv->vgpu.caps & VGT_CAPS_PVMMIO;
+}
+
u32 i915_pipestat_enable_mask(struct drm_i915_private *dev_priv,
enum pipe pipe);
void
@@ -3878,4 +3885,8 @@ static inline int intel_hws_csb_write_index(struct
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+#define PVMMIO_LEVEL_ENABLE(dev_priv, level) \
+ (intel_vgpu_active(dev_priv) && intel_vgpu_has_pvmmio(dev_priv) \
+ && (dev_priv->vgpu.pv_caps & level))
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index eeaa3d5..78a4b9c 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -55,6 +55,18 @@ enum vgt_g2v_type {
#define VGT_CAPS_FULL_48BIT_PPGTT BIT(2)
#define VGT_CAPS_HWSP_EMULATIONBIT(3)
#define VGT_CAPS_HUGE_GTT BIT(4)
+#define VGT_CAPS_PVMMIOBIT(5)
+
+/*
+ * define different levels of PVMMIO optimization
+ */
+enum pvmmio_levels {
+ PVMMIO_ELSP_SUBMIT = 0x1,
+ PVMMIO_PLANE_UPDATE = 0x2,
+ PVMMIO_PLANE_WM_UPDATE = 0x4,
+ PVMMIO_MASTER_IRQ = 0x8,
+ PVMMIO_PPGTT_UPDATE = 0x10,
+};
struct vgt_if {
u64 magic; /* VGT_MAGIC */
@@ -107,7 +119,9 @@ struct vgt_if {
u32 execlist_context_descriptor_lo;
u32 execlist_context_descriptor_hi;
- u32 rsv7[0x200 - 24];/* pad to one page */
+ u32 pvmmio_caps;
+
+ u32 rsv7[0x200 - 25];/* pad to one page */
} __packed;
#define vgtif_reg(x) \
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 869cf4a..219c7c0 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -62,6 +62,7 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
{
u64 magic;
u16 version_major;
+ u32 gvt_caps;
BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
@@ -76,9 +77,27 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
}
dev_priv->vgpu.caps = __raw_i915_read32(dev_priv, vgtif_reg(vgt_caps));
-
dev_priv->vgpu.active = true;
- DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
+
+ if (!intel_vgpu_has_pvmmio(dev_priv)) {
+ DRM_INFO("Virtual GPU for Intel GVT-g detected\n");
+ return;
+ }
+
+ /* If guest wants to enable pvmmio, it needs to enable it explicitly
+* through vgt_if interface, and then read back the enable state from
+* gvt layer.
+*/
+ gvt_caps = __raw_i915_read32(dev_priv, vgtif_reg(pvmmio_caps));
+ dev_priv->vgpu.pv_caps &= gvt_caps;
+ __raw_i915_write32(dev_priv, vgtif_reg(pvmmio_caps),
+ dev_priv->vgpu.pv_caps);
+ if (!dev_priv->vgpu.pv_caps)
+ return;
+
+
+ DRM_INFO("Virtual GPU for Intel GVT-g detected with pvmmio 0x%x\n",
+ dev_priv->vgpu.pv_caps);
}
bool intel_vgpu_has_full_48bit_ppgtt(struct drm_i915_private *dev_priv)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/8] drm/i915: get ready of memory for pvmmio
To enable pvmmio feature, we need to prepare one 4K shared page
which will be accessed by both guest and backend i915 driver used for
data exchagne.
the layout of shared_page also defined as well in this patch.
guest i915 will allocate one page memory and then pass this page's physical
address to backend i915 driver through PVINFO register so that backend i915
driver can access this shared page without hypeviser trap cost
for shared data exchagne via hyperviser read_gpa functionality.
v0: RFC
v1: addressed RFC comment to move both shared_page_lock and shared_page
to i915_virtual_gpu structure
v2: packed i915_virtual_gpu structure
v3: added SHARED_PAGE_SETUP g2v notification for pv shared_page setup
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: He Min
Cc: Jiang Fei
Cc: Gong Zhipeng
Cc: Yuan Hang
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_drv.c| 2 ++
drivers/gpu/drm/i915/i915_drv.h| 4 +++-
drivers/gpu/drm/i915/i915_pvinfo.h | 29 -
drivers/gpu/drm/i915/i915_vgpu.c | 23 +++
4 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index baac35f..557ab67 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -987,6 +987,8 @@ static void i915_mmio_cleanup(struct drm_i915_private
*dev_priv)
intel_teardown_mchbar(dev_priv);
pci_iounmap(pdev, dev_priv->regs);
+ if (intel_vgpu_active(dev_priv) && dev_priv->vgpu.shared_page)
+ free_page((unsigned long)dev_priv->vgpu.shared_page);
}
/**
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b2d7cb..d7a972f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1345,7 +1345,9 @@ struct i915_virtual_gpu {
bool active;
u32 caps;
u32 pv_caps;
-};
+ spinlock_t shared_page_lock;
+ struct gvt_shared_page *shared_page;
+} __packed;
/* used in computing the new watermarks state */
struct intel_wm_config {
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 78a4b9c..aa5eebc 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -24,6 +24,8 @@
#ifndef _I915_PVINFO_H_
#define _I915_PVINFO_H_
+#include "i915_gem.h"
+
/* The MMIO offset of the shared info between guest and host emulator */
#define VGT_PVINFO_PAGE0x78000
#define VGT_PVINFO_SIZE0x1000
@@ -46,9 +48,29 @@ enum vgt_g2v_type {
VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,
VGT_G2V_EXECLIST_CONTEXT_CREATE,
VGT_G2V_EXECLIST_CONTEXT_DESTROY,
+ VGT_G2V_SHARED_PAGE_SETUP,
VGT_G2V_MAX,
};
+struct pv_ppgtt_update {
+ u64 pdp;
+ u64 start;
+ u64 length;
+ u32 cache_level;
+};
+
+/*
+ * shared page(4KB) between gvt and VM, could be allocated by guest driver
+ * or a fixed location in PCI bar 0 region
+ */
+struct gvt_shared_page {
+ u32 reg_addr;
+ u32 elsp_data[I915_NUM_ENGINES * 4];
+ u32 ring_id;
+ u32 disable_irq;
+ struct pv_ppgtt_update pv_ppgtt;
+};
+
/*
* VGT capabilities type
*/
@@ -121,7 +143,12 @@ struct vgt_if {
u32 pvmmio_caps;
- u32 rsv7[0x200 - 25];/* pad to one page */
+ struct {
+ u32 lo;
+ u32 hi;
+ } shared_page_gpa;
+
+ u32 rsv7[0x200 - 27];/* pad to one page */
} __packed;
#define vgtif_reg(x) \
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 219c7c0..63f70bf 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -63,6 +63,7 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
u64 magic;
u16 version_major;
u32 gvt_caps;
+ u64 gpa;
BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
@@ -95,6 +96,28 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
if (!dev_priv->vgpu.pv_caps)
return;
+ dev_priv->vgpu.shared_page = (struct gvt_shared_page *)
+ get_zeroed_page(GFP_KERNEL);
+ if (!dev_priv->vgpu.shared_page) {
+ DRM_ERROR("out of memory for shared page memory\n");
+ return;
+ }
+ gpa = __pa(dev_priv->vgpu.shared_page);
+ __raw_i915_write32(dev_priv, vgtif_reg(shared_page_gpa.lo),
+ lower_32_bits(gpa));
+ __raw_i915_write32(dev_priv, vgtif_reg(shared_page_gpa.hi),
+ upper_32_bits(gpa));
+ if (gpa != __raw_i915_read64(dev_priv,
+ vgtif_reg(shared_page_gpa))) {
+ DRM_ERROR("vgpu: passed shared_page_gpa failed\n");
+ free_page((unsigned long)dev_priv->vgpu.shared_page);
+ dev_priv->vgpu.pv_caps = 0;
+ __raw_i915
[Intel-gfx] [PATCH v3 5/8] drm/i915/gvt: GVTg handle pvmmio_caps PVINFO register
implement enable_pvmmio PVINFO register handler in GVTg to
control different level pvmmio optimization within guest.
report VGT_CAPS_PVMMIO capability in pvinfo page for guest.
v0: RFC
v1: rebase
v2: rebase
v3: renamed enable_pvmmio to pvmmio_caps which is used for host
pv caps.
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Min He
Cc: Fei Jiang
Cc: Zhipeng Gong
Cc: Hang Yuan
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/gvt.h | 3 +++
drivers/gpu/drm/i915/gvt/handlers.c | 7 ---
drivers/gpu/drm/i915/gvt/vgpu.c | 4
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 31f6cdb..5f6b2d5 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -52,6 +52,9 @@
#define GVT_MAX_VGPU 8
+#define _vgtif_reg(x) \
+ (VGT_PVINFO_PAGE + offsetof(struct vgt_if, x))
+
enum {
INTEL_GVT_HYPERVISOR_XEN = 0,
INTEL_GVT_HYPERVISOR_KVM,
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index d262587..6cb139f 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1145,9 +1145,6 @@ static int sbi_ctl_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
return 0;
}
-#define _vgtif_reg(x) \
- (VGT_PVINFO_PAGE + offsetof(struct vgt_if, x))
-
static int pvinfo_mmio_read(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
@@ -1168,6 +1165,7 @@ static int pvinfo_mmio_read(struct intel_vgpu *vgpu,
unsigned int offset,
break;
case 0x78010: /* vgt_caps */
case 0x7881c:
+ case _vgtif_reg(pvmmio_caps):
break;
default:
invalid_read = true;
@@ -1241,6 +1239,9 @@ static int pvinfo_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
case _vgtif_reg(g2v_notify):
ret = handle_g2v_notification(vgpu, data);
break;
+ case _vgtif_reg(pvmmio_caps):
+ DRM_INFO("vgpu id=%d pvmmio caps =0x%x\n", vgpu->id, data);
+ break;
/* add xhot and yhot to handled list to avoid error log */
case _vgtif_reg(cursor_x_hot):
case _vgtif_reg(cursor_y_hot):
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index a4e8e3c..84244ab 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -47,6 +47,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) = VGT_CAPS_FULL_48BIT_PPGTT;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HWSP_EMULATION;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HUGE_GTT;
+ vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_PVMMIO;
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) =
vgpu_aperture_gmadr_base(vgpu);
@@ -62,6 +63,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
vgpu_vreg_t(vgpu, vgtif_reg(cursor_x_hot)) = UINT_MAX;
vgpu_vreg_t(vgpu, vgtif_reg(cursor_y_hot)) = UINT_MAX;
+
gvt_dbg_core("Populate PVINFO PAGE for vGPU %d\n", vgpu->id);
gvt_dbg_core("aperture base [GMADR] 0x%llx size 0x%llx\n",
vgpu_aperture_gmadr_base(vgpu), vgpu_aperture_sz(vgpu));
@@ -524,6 +526,7 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu,
bool dmlr,
struct intel_gvt *gvt = vgpu->gvt;
struct intel_gvt_workload_scheduler *scheduler = &gvt->scheduler;
unsigned int resetting_eng = dmlr ? ALL_ENGINES : engine_mask;
+ int pvmmio_caps = vgpu_vreg(vgpu, _vgtif_reg(pvmmio_caps));
gvt_dbg_core("--\n");
gvt_dbg_core("resseting vgpu%d, dmlr %d, engine_mask %08x\n",
@@ -555,6 +558,7 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu,
bool dmlr,
intel_vgpu_reset_mmio(vgpu, dmlr);
populate_pvinfo_page(vgpu);
+ vgpu_vreg(vgpu, _vgtif_reg(pvmmio_caps)) = pvmmio_caps;
intel_vgpu_reset_display(vgpu);
if (dmlr) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/8] i915 pvmmio to improve GVTg performance
To improve GVTg performance, it could reduce the mmio access trap numbers within guest driver in some certain scenarios since mmio access trap will introuduce vm exit/vm enter cost. the solution in this patch set is to setup a shared memory region which accessed both by guest and GVTg without trap cost. the shared memory region is allocated by guest driver and guest driver will pass the region's memory guest physical address to GVTg through PVINFO register and later GVTg can access this region directly without trap cost to achieve data exchange purpose between guest and GVTg. in this patch set, 2 kind of pvmmio optimization implemented which is controlled by pvmmio_caps PVINO register with different level flag. 1. workload submission (context submission): reduce 4 traps to 1 trap. 2. ppgtt update: eliminate the cost of ppgtt write protection. based on the experiment, the performance was gained 4 percent (average) improvment with regard to both media and 3D workload benchmarks. based on the pvmmio framework, it could achive more sceneario optimization such as globle GTT update, display plane and water mark update with guest. v0: RFC patch set v1: addressed RFC review comments v2: addressed v1 review comments, added pv callbacks for pv operations v3: 1. addressed v2 review comments, removed pv callbacks code duplication in v2 and unified pv calls under g2v notification register. different g2v pv notifications defined. 2. dropped pv master irq feature due to hard conflict with recnet i915 change and take time to rework. Xiaolin Zhang (8): drm/i915: introduced pv capability for vgpu drm/i915: get ready of memory for pvmmio drm/i915: context submission pvmmio optimization drm/i915: ppgtt update pvmmio optimization drm/i915/gvt: GVTg handle pvmmio_caps PVINFO register drm/i915/gvt: GVTg handle shared_page setup drm/i915/gvt: GVTg support context submission pvmmio optimization drm/i915/gvt: GVTg support ppgtt pvmmio optimization drivers/gpu/drm/i915/gvt/gtt.c | 318 drivers/gpu/drm/i915/gvt/gtt.h | 9 + drivers/gpu/drm/i915/gvt/gvt.h | 12 +- drivers/gpu/drm/i915/gvt/handlers.c | 94 +- drivers/gpu/drm/i915/gvt/vgpu.c | 31 drivers/gpu/drm/i915/i915_drv.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 15 +- drivers/gpu/drm/i915/i915_gem.c | 3 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 67 +++ drivers/gpu/drm/i915/i915_pvinfo.h | 47 - drivers/gpu/drm/i915/i915_vgpu.c| 48 - drivers/gpu/drm/i915/intel_lrc.c| 33 +++- drivers/gpu/drm/i915/intel_ringbuffer.h | 3 + 13 files changed, 668 insertions(+), 14 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/8] drm/i915: context submission pvmmio optimization
It is performance optimization to reduce mmio trap numbers from 4 to
1 durning ELSP porting writing (context submission).
When context subission, to cache elsp_data[4] values in
the shared page, the last elsp_data[0] port writing will be trapped
to gvt for real context submission.
Use PVMMIO_ELSP_SUBMIT to control this level of pvmmio optimization.
v0: RFC
v1: rebase
v2: added pv ops for pv context submission. to maximize code resuse,
introduced 2 more ops (submit_ports & preempt_context) instead of 1 op
(set_default_submission) in engine structure. pv version of
submit_ports and preempt_context implemented.
v3:
1. to reduce more code duplication, code refactor and replaced 2 ops
"submit_ports & preempt_contex" from v2 by 1 ops "write_desc"
in engine structure. pv version of write_des implemented.
2. added VGT_G2V_ELSP_SUBMIT for g2v pv notification.
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: He Min
Cc: Jiang Fei
Cc: Gong Zhipeng
Cc: Yuan Hang
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/i915_pvinfo.h | 1 +
drivers/gpu/drm/i915/i915_vgpu.c| 2 ++
drivers/gpu/drm/i915/intel_lrc.c| 33 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +++
4 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index aa5eebc..3da644d 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -49,6 +49,7 @@ enum vgt_g2v_type {
VGT_G2V_EXECLIST_CONTEXT_CREATE,
VGT_G2V_EXECLIST_CONTEXT_DESTROY,
VGT_G2V_SHARED_PAGE_SETUP,
+ VGT_G2V_ELSP_SUBMIT,
VGT_G2V_MAX,
};
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 63f70bf..82120f6 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -85,6 +85,8 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
return;
}
+ dev_priv->vgpu.pv_caps = PVMMIO_ELSP_SUBMIT;
+
/* If guest wants to enable pvmmio, it needs to enable it explicitly
* through vgt_if interface, and then read back the enable state from
* gvt layer.
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ff0e2b3..660e24c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -391,8 +391,10 @@ static u64 execlists_update_context(struct i915_request
*rq)
return ce->lrc_desc;
}
-static inline void write_desc(struct intel_engine_execlists *execlists, u64
desc, u32 port)
+static inline void write_desc(struct intel_engine_cs *engine,
+ u64 desc, u32 port)
{
+ struct intel_engine_execlists *execlists = &engine->execlists;
if (execlists->ctrl_reg) {
writel(lower_32_bits(desc), execlists->submit_reg + port * 2);
writel(upper_32_bits(desc), execlists->submit_reg + port * 2 +
1);
@@ -402,6 +404,24 @@ static inline void write_desc(struct
intel_engine_execlists *execlists, u64 desc
}
}
+static inline void write_desc_pv(struct intel_engine_cs *engine,
+ u64 desc, u32 port)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ u32 *elsp_data;
+
+ spin_lock(&engine->i915->vgpu.shared_page_lock);
+ elsp_data = engine->i915->vgpu.shared_page->elsp_data;
+ elsp_data[engine->id * 4 + port * 2] = upper_32_bits(desc);
+ elsp_data[engine->id * 4 + port * 2 + 1] = lower_32_bits(desc);
+ if (port == 0) {
+ engine->i915->vgpu.shared_page->ring_id = engine->id;
+ __raw_i915_write32(dev_priv, vgtif_reg(g2v_notify),
+ VGT_G2V_ELSP_SUBMIT);
+ }
+ spin_unlock(&engine->i915->vgpu.shared_page_lock);
+}
+
static void execlists_submit_ports(struct intel_engine_cs *engine)
{
struct intel_engine_execlists *execlists = &engine->execlists;
@@ -450,7 +470,7 @@ static void execlists_submit_ports(struct intel_engine_cs
*engine)
desc = 0;
}
- write_desc(execlists, desc, n);
+ engine->write_desc(engine, desc, n);
}
/* we need to manually load the submit queue */
@@ -504,9 +524,9 @@ static void inject_preempt_context(struct intel_engine_cs
*engine)
*/
GEM_TRACE("%s\n", engine->name);
for (n = execlists_num_ports(execlists); --n; )
- write_desc(execlists, 0, n);
+ engine->write_desc(engine, 0, n);
- write_desc(execlists, ce->lrc_desc, n);
+ engine->write_desc(engine, ce->lrc_desc, n);
/* we need to manually load the submit queue */
if (execlists->ctrl_reg)
@@ -2134,6 +2154,11 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->reset.prepare = execlists_rese
[Intel-gfx] [PATCH v3 6/8] drm/i915/gvt: GVTg handle shared_page setup
GVTg implemented shared_page setup operation and read_shared_page
functionality based on hypervisor_read_gpa().
the shared_page_gpa was passed from guest driver through PVINFO
shared_page_gpa register.
v0: RFC
v1: rebase
v2: rebase
v3: added shared_page_gpa check and if read_gpa failure, return zero
memory and handle VGT_G2V_SHARED_PAGE_SETUP g2v notification
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Min He
Cc: Fei Jiang
Cc: Zhipeng Gong
Cc: Hang Yuan
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/gvt.h | 5 -
drivers/gpu/drm/i915/gvt/handlers.c | 39 +
drivers/gpu/drm/i915/gvt/vgpu.c | 24 +++
3 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 5f6b2d5..e013962 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -235,6 +235,8 @@ struct intel_vgpu {
struct completion vblank_done;
u32 scan_nonprivbb;
+ u64 shared_page_gpa;
+ bool shared_page_enabled;
};
/* validating GM healthy status*/
@@ -693,7 +695,8 @@ int intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_debugfs_remove_vgpu(struct intel_vgpu *vgpu);
int intel_gvt_debugfs_init(struct intel_gvt *gvt);
void intel_gvt_debugfs_clean(struct intel_gvt *gvt);
-
+int intel_gvt_read_shared_page(struct intel_vgpu *vgpu,
+ unsigned int offset, void *buf, unsigned long len);
#include "trace.h"
#include "mpt.h"
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 6cb139f..16ef41b 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1166,6 +1166,8 @@ static int pvinfo_mmio_read(struct intel_vgpu *vgpu,
unsigned int offset,
case 0x78010: /* vgt_caps */
case 0x7881c:
case _vgtif_reg(pvmmio_caps):
+ case _vgtif_reg(shared_page_gpa.lo):
+ case _vgtif_reg(shared_page_gpa.hi):
break;
default:
invalid_read = true;
@@ -1183,6 +1185,7 @@ static int handle_g2v_notification(struct intel_vgpu
*vgpu, int notification)
intel_gvt_gtt_type_t root_entry_type = GTT_TYPE_PPGTT_ROOT_L4_ENTRY;
struct intel_vgpu_mm *mm;
u64 *pdps;
+ unsigned long gfn;
pdps = (u64 *)&vgpu_vreg64_t(vgpu, vgtif_reg(pdp[0]));
@@ -1196,6 +1199,11 @@ static int handle_g2v_notification(struct intel_vgpu
*vgpu, int notification)
case VGT_G2V_PPGTT_L3_PAGE_TABLE_DESTROY:
case VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY:
return intel_vgpu_put_ppgtt_mm(vgpu, pdps);
+ case VGT_G2V_SHARED_PAGE_SETUP:
+ gfn = vgpu->shared_page_gpa >> PAGE_SHIFT;
+ if (intel_gvt_hypervisor_is_valid_gfn(vgpu, gfn))
+ vgpu->shared_page_enabled = true;
+ break;
case VGT_G2V_EXECLIST_CONTEXT_CREATE:
case VGT_G2V_EXECLIST_CONTEXT_DESTROY:
case 1: /* Remove this in guest driver. */
@@ -1223,6 +1231,33 @@ static int send_display_ready_uevent(struct intel_vgpu
*vgpu, int ready)
return kobject_uevent_env(kobj, KOBJ_ADD, env);
}
+static int handle_shared_page_gpa(struct intel_vgpu *vgpu,
+ unsigned int offset, unsigned int data)
+{
+ bool partial_update = false;
+ unsigned long gpa, gfn;
+
+ if (offset == _vgtif_reg(shared_page_gpa.lo)) {
+ if (vgpu_vreg_t(vgpu, vgtif_reg(shared_page_gpa.hi)) == -1U)
+ partial_update = true;
+ }
+ if (offset == _vgtif_reg(shared_page_gpa.hi)) {
+ if (vgpu_vreg_t(vgpu, vgtif_reg(shared_page_gpa.lo)) == -1U)
+ partial_update = true;
+ }
+ if (partial_update)
+ return 0;
+
+ gpa = vgpu_vreg64_t(vgpu, vgtif_reg(shared_page_gpa));
+ gfn = gpa >> PAGE_SHIFT;
+ if (!intel_gvt_hypervisor_is_valid_gfn(vgpu, gfn)) {
+ vgpu_vreg_t(vgpu, vgtif_reg(pvmmio_caps)) = 0;
+ return 0;
+ }
+ vgpu->shared_page_gpa = gpa;
+ return 0;
+}
+
static int pvinfo_mmio_write(struct intel_vgpu *vgpu, unsigned int offset,
void *p_data, unsigned int bytes)
{
@@ -1242,6 +1277,10 @@ static int pvinfo_mmio_write(struct intel_vgpu *vgpu,
unsigned int offset,
case _vgtif_reg(pvmmio_caps):
DRM_INFO("vgpu id=%d pvmmio caps =0x%x\n", vgpu->id, data);
break;
+ case _vgtif_reg(shared_page_gpa.lo):
+ case _vgtif_reg(shared_page_gpa.hi):
+ handle_shared_page_gpa(vgpu, offset, data);
+ break;
/* add xhot and yhot to handled list to avoid error log */
case _vgtif_reg(cursor_x_hot):
case _vgtif_reg(cursor_y_hot):
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 84244ab..40aaae8 100644
--- a/dr
[Intel-gfx] [PATCH v3 7/8] drm/i915/gvt: GVTg support context submission pvmmio optimization
implemented context submission pvmmio optimizaiton with GVTg.
GVTg to read context submission data (elsp_data) from the shared_page
directly without trap cost to improve guest GPU peformrnace.
v0: RFC
v1: rebase
v2: rebase
v3: report pv context submission cap and handle VGT_G2V_ELSP_SUBMIT
g2v pv notification.
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Min He
Cc: Fei Jiang
Cc: Zhipeng Gong
Cc: Hang Yuan
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/gvt.h | 4
drivers/gpu/drm/i915/gvt/handlers.c | 39 -
drivers/gpu/drm/i915/gvt/vgpu.c | 2 ++
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index e013962..c8bd1f3 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -55,6 +55,10 @@
#define _vgtif_reg(x) \
(VGT_PVINFO_PAGE + offsetof(struct vgt_if, x))
+#define VGPU_PVMMIO(vgpu, level) \
+ ((vgpu_vreg_t(vgpu, vgtif_reg(pvmmio_caps)) & level) \
+ && vgpu->shared_page_enabled)
+
enum {
INTEL_GVT_HYPERVISOR_XEN = 0,
INTEL_GVT_HYPERVISOR_KVM,
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 16ef41b..1659bd1 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1180,12 +1180,46 @@ static int pvinfo_mmio_read(struct intel_vgpu *vgpu,
unsigned int offset,
return 0;
}
+static int intel_vgpu_g2v_pv_elsp_submit(struct intel_vgpu *vgpu)
+{
+ int ring_id;
+ struct intel_vgpu_execlist *execlist;
+ u32 elsp_data[4 * I915_NUM_ENGINES];
+ u32 elsp_data_off;
+ u32 ring_id_off;
+ int ret = -EINVAL;
+
+ if (!VGPU_PVMMIO(vgpu, PVMMIO_ELSP_SUBMIT))
+ return ret;
+
+ ring_id_off = offsetof(struct gvt_shared_page, ring_id);
+ if (intel_gvt_read_shared_page(vgpu, ring_id_off, &ring_id, 4))
+ return ret;
+
+ if (WARN_ON(ring_id < 0 || ring_id >= I915_NUM_ENGINES))
+ return ret;
+
+ elsp_data_off = offsetof(struct gvt_shared_page, elsp_data);
+ if (intel_gvt_read_shared_page(vgpu, elsp_data_off, &elsp_data,
+ 16 * I915_NUM_ENGINES))
+ return ret;
+
+ execlist = &vgpu->submission.execlist[ring_id];
+ execlist->elsp_dwords.data[3] = elsp_data[ring_id * 4 + 2];
+ execlist->elsp_dwords.data[2] = elsp_data[ring_id * 4 + 3];
+ execlist->elsp_dwords.data[1] = elsp_data[ring_id * 4 + 0];
+ execlist->elsp_dwords.data[0] = elsp_data[ring_id * 4 + 1];
+
+ return intel_vgpu_submit_execlist(vgpu, ring_id);
+}
+
static int handle_g2v_notification(struct intel_vgpu *vgpu, int notification)
{
intel_gvt_gtt_type_t root_entry_type = GTT_TYPE_PPGTT_ROOT_L4_ENTRY;
struct intel_vgpu_mm *mm;
u64 *pdps;
unsigned long gfn;
+ int ret = 0;
pdps = (u64 *)&vgpu_vreg64_t(vgpu, vgtif_reg(pdp[0]));
@@ -1204,6 +1238,9 @@ static int handle_g2v_notification(struct intel_vgpu
*vgpu, int notification)
if (intel_gvt_hypervisor_is_valid_gfn(vgpu, gfn))
vgpu->shared_page_enabled = true;
break;
+ case VGT_G2V_ELSP_SUBMIT:
+ ret = intel_vgpu_g2v_pv_elsp_submit(vgpu);
+ break;
case VGT_G2V_EXECLIST_CONTEXT_CREATE:
case VGT_G2V_EXECLIST_CONTEXT_DESTROY:
case 1: /* Remove this in guest driver. */
@@ -1211,7 +1248,7 @@ static int handle_g2v_notification(struct intel_vgpu
*vgpu, int notification)
default:
gvt_vgpu_err("Invalid PV notification %d\n", notification);
}
- return 0;
+ return ret;
}
static int send_display_ready_uevent(struct intel_vgpu *vgpu, int ready)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 40aaae8..f98b591 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -49,6 +49,8 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HUGE_GTT;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_PVMMIO;
+ vgpu_vreg_t(vgpu, vgtif_reg(pvmmio_caps)) = PVMMIO_ELSP_SUBMIT;
+
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) =
vgpu_aperture_gmadr_base(vgpu);
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.size)) =
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 8/8] drm/i915/gvt: GVTg support ppgtt pvmmio optimization
This patch handles ppgtt update from g2v notification.
It read out ppgtt pte entries from guest pte tables page and
convert them to host pfns.
It creates local ppgtt tables and insert the content pages
into the local ppgtt tables directly, which does not track
the usage of guest page table and removes the cost of write
protection from the original shadow page mechansim.
v0: RFC
v1: rebase
v2: rebase
v3: report pv pggtt cap to guest
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Min He
Cc: Fei Jiang
Cc: Zhipeng Gong
Cc: Hang Yuan
Cc: Zhiyuan Lv
Signed-off-by: Xiaolin Zhang
---
drivers/gpu/drm/i915/gvt/gtt.c | 318
drivers/gpu/drm/i915/gvt/gtt.h | 9 +
drivers/gpu/drm/i915/gvt/handlers.c | 9 +
drivers/gpu/drm/i915/gvt/vgpu.c | 3 +-
4 files changed, 338 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 2402395..4a0a221 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -1744,6 +1744,26 @@ static int ppgtt_handle_guest_write_page_table_bytes(
return 0;
}
+static void invalidate_mm_pv(struct intel_vgpu_mm *mm)
+{
+ struct intel_vgpu *vgpu = mm->vgpu;
+ struct intel_gvt *gvt = vgpu->gvt;
+ struct intel_gvt_gtt *gtt = &gvt->gtt;
+ struct intel_gvt_gtt_pte_ops *ops = gtt->pte_ops;
+ struct intel_gvt_gtt_entry se;
+
+ i915_ppgtt_close(&mm->ppgtt->vm);
+ i915_ppgtt_put(mm->ppgtt);
+
+ ppgtt_get_shadow_root_entry(mm, &se, 0);
+ if (!ops->test_present(&se))
+ return;
+ se.val64 = 0;
+ ppgtt_set_shadow_root_entry(mm, &se, 0);
+
+ mm->ppgtt_mm.shadowed = false;
+}
+
static void invalidate_ppgtt_mm(struct intel_vgpu_mm *mm)
{
struct intel_vgpu *vgpu = mm->vgpu;
@@ -1756,6 +1776,11 @@ static void invalidate_ppgtt_mm(struct intel_vgpu_mm *mm)
if (!mm->ppgtt_mm.shadowed)
return;
+ if (VGPU_PVMMIO(mm->vgpu, PVMMIO_PPGTT_UPDATE)) {
+ invalidate_mm_pv(mm);
+ return;
+ }
+
for (index = 0; index < ARRAY_SIZE(mm->ppgtt_mm.shadow_pdps); index++) {
ppgtt_get_shadow_root_entry(mm, &se, index);
@@ -1773,6 +1798,26 @@ static void invalidate_ppgtt_mm(struct intel_vgpu_mm *mm)
mm->ppgtt_mm.shadowed = false;
}
+static int shadow_mm_pv(struct intel_vgpu_mm *mm)
+{
+ struct intel_vgpu *vgpu = mm->vgpu;
+ struct intel_gvt *gvt = vgpu->gvt;
+ struct intel_gvt_gtt_entry se;
+
+ mm->ppgtt = i915_ppgtt_create(gvt->dev_priv, NULL);
+ if (IS_ERR(mm->ppgtt)) {
+ gvt_vgpu_err("fail to create ppgtt for pdp 0x%llx\n",
+ px_dma(&mm->ppgtt->pml4));
+ return PTR_ERR(mm->ppgtt);
+ }
+
+ se.type = GTT_TYPE_PPGTT_ROOT_L4_ENTRY;
+ se.val64 = px_dma(&mm->ppgtt->pml4);
+ ppgtt_set_shadow_root_entry(mm, &se, 0);
+ mm->ppgtt_mm.shadowed = true;
+
+ return 0;
+}
static int shadow_ppgtt_mm(struct intel_vgpu_mm *mm)
{
@@ -1787,6 +1832,9 @@ static int shadow_ppgtt_mm(struct intel_vgpu_mm *mm)
if (mm->ppgtt_mm.shadowed)
return 0;
+ if (VGPU_PVMMIO(mm->vgpu, PVMMIO_PPGTT_UPDATE))
+ return shadow_mm_pv(mm);
+
mm->ppgtt_mm.shadowed = true;
for (index = 0; index < ARRAY_SIZE(mm->ppgtt_mm.guest_pdps); index++) {
@@ -2766,3 +2814,273 @@ void intel_vgpu_reset_gtt(struct intel_vgpu *vgpu)
intel_vgpu_destroy_all_ppgtt_mm(vgpu);
intel_vgpu_reset_ggtt(vgpu, true);
}
+
+int intel_vgpu_g2v_pv_ppgtt_alloc_4lvl(struct intel_vgpu *vgpu,
+ u64 pdps[])
+{
+ struct intel_vgpu_mm *mm;
+ int ret = 0;
+ u32 offset;
+ struct pv_ppgtt_update pv_ppgtt;
+
+ offset = offsetof(struct gvt_shared_page, pv_ppgtt);
+ intel_gvt_read_shared_page(vgpu, offset, &pv_ppgtt, sizeof(pv_ppgtt));
+
+ mm = intel_vgpu_find_ppgtt_mm(vgpu, &pv_ppgtt.pdp);
+ if (!mm) {
+ gvt_vgpu_err("failed to find pdp 0x%llx\n", pv_ppgtt.pdp);
+ ret = -EINVAL;
+ } else {
+ ret = mm->ppgtt->vm.allocate_va_range(&mm->ppgtt->vm,
+ pv_ppgtt.start, pv_ppgtt.length);
+ if (ret)
+ gvt_vgpu_err("failed to alloc %llx\n", pv_ppgtt.pdp);
+ }
+
+ return ret;
+}
+
+int intel_vgpu_g2v_pv_ppgtt_clear_4lvl(struct intel_vgpu *vgpu,
+ u64 pdps[])
+{
+ struct intel_vgpu_mm *mm;
+ int ret = 0;
+ u32 offset;
+ struct pv_ppgtt_update pv_ppgtt;
+
+ offset = offsetof(struct gvt_shared_page, pv_ppgtt);
+ intel_gvt_read_shared_page(vgpu, offset, &pv_ppgtt, sizeof(pv_ppgtt));
+ mm = intel_vgpu_find_ppgtt_mm(vgpu, &pv_ppgtt.pdp);
+ if (!mm) {
+ gvt_vgpu_err("failed to find pdp 0x%llx\n", pv_ppgtt.pdp);
+ ret = -EINVAL;
+
Re: [Intel-gfx] [RFC 2/7] drm/i915: Introduce runtime device info
On 12/11/2018 17:36, Ville Syrjälä wrote: On Mon, Nov 12, 2018 at 05:12:37PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Idea of runtime device info is to contain all fields from the existing device info which are modified at runtime. Initially we move there fields which are never set from the static tables ie.: num_rings, num_sprites, num_scalers, If we accept that num_sprites[fused_off_pipe] can be non-zero we could keep num_sprites and num_scalers in the static info. I don't *think* we have any code that would rely on those being zero. Works for me, that is, I don't have a strong opinion on this one. If display folks agree on this direction you can either implement this ahead, or I can incorporate the move in this series. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/7] drm/i915: Move all runtime modified device info fields into runtime info
On 12/11/2018 17:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-11-12 17:12:38)
struct intel_device_info {
- u16 device_id;
u16 gen_mask;
- u8 gen;
+ u8 __gen;
u8 gt; /* GT number, 0 if undefined */
- intel_ring_mask_t ring_mask; /* Rings supported by the HW */
- u8 num_pipes;
+ intel_ring_mask_t __ring_mask; /* Rings supported by the HW */
+ u8 __num_pipes;
enum intel_platform platform;
u32 platform_mask;
- enum intel_ppgtt ppgtt;
- unsigned int page_sizes; /* page sizes supported by the HW */
+ enum intel_ppgtt __ppgtt;
ppgtt mode is static.
What about:
@@ -868,7 +867,7 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
if (IS_GEN6(dev_priv) && intel_vtd_active()) {
DRM_INFO("Disabling ppGTT for VT-d support\n");
- info->ppgtt = INTEL_PPGTT_NONE;
+ runtime_info->ppgtt = INTEL_PPGTT_NONE;
}
/* Initialize command stream timestamp frequency */
And:
@@ -1711,7 +1711,7 @@ int i915_gem_huge_page_mock_selftests(void)
return -ENOMEM;
/* Pretend to be a device which supports the 48b PPGTT */
- mkwrite_device_info(dev_priv)->ppgtt = INTEL_PPGTT_FULL_4LVL;
+ dev_priv->runtime_info.ppgtt = INTEL_PPGTT_FULL_4LVL;
pdev = dev_priv->drm.pdev;
dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(39));
?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
On 12/11/2018 17:25, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-11-12 17:12:39) From: Tvrtko Ursulin Now that we are down to one caller, which does not even modify copied device info, we can remove the mkwrite_device_info helper and convert the device info pointer itself to be a pointer to static table instead of a copy. The copy was deliberate to avoid the extra pointer. How does the change in code size now compare? AFAIR grows a bit, but overall series still ends up overall smaller. I need to re-run the numbers for more concrete info. However, if we keep having a copy, ie. do not make device info properly read-only, are we still interested in splitting the two? Benefit would be diminished, but presumably people still think it would be worth it? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/7] drm/i915: Introduce subplatform concept
On 12/11/2018 17:29, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-11-12 17:12:41) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index 00758d11047b..b9d08428f35b 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -118,6 +118,8 @@ intel_device_info_dump_runtime(const struct intel_runtime_device_info *info, drm_printf(p, "CS timestamp frequency: %u kHz\n", info->cs_timestamp_frequency_khz); + drm_printf(p, "Subplatform mask: %x\n", info->subplatform_mask); Any chance for a magic decoder ring? Quick identification of ult/ulx I think would be very nice. Yes I wasn't happy with not doing that myself. So I think it is definitely needed. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/7] drm/i915: Move all runtime modified device info fields into runtime info
On 12/11/2018 21:22, Lucas De Marchi wrote: On Mon, Nov 12, 2018 at 05:12:38PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin After the previous change which cleared the static tables from effectively unused storage, we now replicate entries which have defaults set from there, but can be overriden at runtime. For this class of variables all accessor macros and call sites are changed to use the runtime version. Therefore at driver load we need to copy over these variables from static to the runtime table. We add double prefixes to the affected device info members to signify they are special and to catch all current and future users. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Jani Nikula --- [...] diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c index 43ed8b28aeaa..b6849ca11e01 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c @@ -174,12 +174,11 @@ struct drm_i915_private *mock_gem_device(void) /* Using the global GTT may ask questions about KMS users, so prepare */ drm_mode_config_init(&i915->drm); - mkwrite_device_info(i915)->gen = -1; + i915->runtime_info.gen = -1; this seems the only place that is setting gen to something not statically defined. And it also misses that it'd need to set gen_mask, too. Could we rather define a device_info for the mock device with the proper values rather than doing this? That would be indeed preferable and I hated the runtime edit of the gen myself. For the RFC I just did not spend the time to investigate why the mock device needs this etc. Marking as TODO. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix plane allocation/free functions
Use intel_plane_destroy_state in intel_plane_free to free the state.
Also fix intel_plane_alloc() to use __drm_atomic_helper_plane_reset(),
to get sane defaults from the atomic core.
Signed-off-by: Maarten Lankhorst
Reported-by: Ville Syrjälä
Cc: Ville Syrjälä
Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 40 ---
drivers/gpu/drm/i915/intel_drv.h | 5 ++-
drivers/gpu/drm/i915/intel_sprite.c | 29
3 files changed, 23 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7d3685075201..905f8ef3ba4f 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -36,29 +36,31 @@
#include
#include "intel_drv.h"
-/**
- * intel_create_plane_state - create plane state object
- * @plane: drm plane
- *
- * Allocates a fresh plane state for the given plane and sets some of
- * the state values to sensible initial values.
- *
- * Returns: A newly allocated plane state, or NULL on failure
- */
-struct intel_plane_state *
-intel_create_plane_state(struct drm_plane *plane)
+struct intel_plane *intel_plane_alloc(void)
{
- struct intel_plane_state *state;
+ struct intel_plane_state *plane_state;
+ struct intel_plane *plane;
- state = kzalloc(sizeof(*state), GFP_KERNEL);
- if (!state)
- return NULL;
+ plane = kzalloc(sizeof(*plane), GFP_KERNEL);
+ if (!plane)
+ return ERR_PTR(-ENOMEM);
- state->base.plane = plane;
- state->base.rotation = DRM_MODE_ROTATE_0;
- state->scaler_id = -1;
+ plane_state = kzalloc(sizeof(*plane_state), GFP_KERNEL);
+ if (!plane_state) {
+ kfree(plane);
+ return ERR_PTR(-ENOMEM);
+ }
- return state;
+ __drm_atomic_helper_plane_reset(&plane->base, &plane_state->base);
+ plane_state->scaler_id = -1;
+
+ return plane;
+}
+
+void intel_plane_free(struct intel_plane *plane)
+{
+ intel_plane_destroy_state(&plane->base, plane->base.state);
+ kfree(plane);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 10a5df66e4eb..2a897e174ed5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2219,8 +2219,6 @@ void intel_pipe_update_end(struct intel_crtc_state
*new_crtc_state);
int intel_plane_check_stride(const struct intel_plane_state *plane_state);
int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state);
int chv_plane_check_rotation(const struct intel_plane_state *plane_state);
-struct intel_plane *intel_plane_alloc(void);
-void intel_plane_free(struct intel_plane *plane);
struct intel_plane *
skl_universal_plane_create(struct drm_i915_private *dev_priv,
enum pipe pipe, enum plane_id plane_id);
@@ -2282,7 +2280,8 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
struct intel_crtc_state *crtc_state);
/* intel_atomic_plane.c */
-struct intel_plane_state *intel_create_plane_state(struct drm_plane *plane);
+struct intel_plane *intel_plane_alloc(void);
+void intel_plane_free(struct intel_plane *plane);
struct drm_plane_state *intel_plane_duplicate_state(struct drm_plane *plane);
void intel_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index facf7ca8f14f..7db6d060efe7 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1982,35 +1982,6 @@ static bool skl_plane_has_ccs(struct drm_i915_private
*dev_priv,
plane_id == PLANE_SPRITE0);
}
-struct intel_plane *intel_plane_alloc(void)
-{
- struct intel_plane_state *plane_state;
- struct intel_plane *plane;
-
- plane = kzalloc(sizeof(*plane), GFP_KERNEL);
- if (!plane)
- return ERR_PTR(-ENOMEM);
-
- plane_state = intel_create_plane_state(&plane->base);
- if (!plane_state) {
- kfree(plane);
- return ERR_PTR(-ENOMEM);
- }
-
- plane->base.state = &plane_state->base;
-
- return plane;
-}
-
-void intel_plane_free(struct intel_plane *plane)
-{
- struct intel_plane_state *plane_state =
- to_intel_plane_state(plane->base.state);
-
- kfree(plane_state);
- kfree(plane);
-}
-
struct intel_plane *
skl_universal_plane_create(struct drm_i915_private *dev_priv,
enum pipe pipe, enum plane_id plane_id)
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Switch LSPCON to PCON mode if it's in LS mode
Regards
Shashank
On 11/7/2018 10:48 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We no longer change LSPCON into PCON mode if it boots up in
LS mode. This was broken by some code shuffling in
commit 96e35598cead ("drm/i915: Check LSPCON vendor OUI").
I actually can't see a reason why that code shuffling had
to be done. The commit msg notes it but doesn't justify it
in any way.
Its been some time, but AFAIR this shuffling was done because we wanted
to make sure LSPCON is in DP/PCON personality, before we try to read
DCPD and vendor OUI. I probably missed to add this reason in commit
message. There were few LSPCON devices, which due to old FW version, or
some one or other reason, were booting in LS mode. We wanted to make
sure that probing, mode change and delay related stuff is all taken care
in lspcon_probe function, and after probing, LSPCON is ready to be used
in PCON personality.
But I guess we'll keep the code in its current
place anyway and just make the "switch to PCON mode" part
effective once again.
Cc: Shashank Sharma
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Tested-by: Tvrtko Ursulin
Fixes: 96e35598cead ("drm/i915: Check LSPCON vendor OUI")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_lspcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index fff32b31c7df..96a8d9524b0c 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -230,7 +230,7 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
* In this way, it will work with both HDMI 1.4 sinks as well as HDMI
* 2.0 sinks.
*/
- if (lspcon->active && lspcon->mode != DRM_LSPCON_MODE_PCON) {
+ if (lspcon->mode != DRM_LSPCON_MODE_PCON) {
Agree, this became irrelevant once we added the vendor detection code,
and decided to call it active, only when probing, dpcd_read and
vendor_detection is all good.
Reviewed-by: Shashank Sharma
if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON) < 0) {
DRM_ERROR("LSPCON mode change to PCON failed\n");
return false;
- Shashank
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/7] drm/i915: Move all runtime modified device info fields into runtime info
Quoting Tvrtko Ursulin (2018-11-13 09:13:47)
>
> On 12/11/2018 17:24, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-11-12 17:12:38)
> >> struct intel_device_info {
> >> - u16 device_id;
> >> u16 gen_mask;
> >>
> >> - u8 gen;
> >> + u8 __gen;
> >> u8 gt; /* GT number, 0 if undefined */
> >> - intel_ring_mask_t ring_mask; /* Rings supported by the HW */
> >> - u8 num_pipes;
> >> + intel_ring_mask_t __ring_mask; /* Rings supported by the HW */
> >> + u8 __num_pipes;
> >>
> >> enum intel_platform platform;
> >> u32 platform_mask;
> >>
> >> - enum intel_ppgtt ppgtt;
> >> - unsigned int page_sizes; /* page sizes supported by the HW */
> >> + enum intel_ppgtt __ppgtt;
> >
> > ppgtt mode is static.
>
> What about:
>
> @@ -868,7 +867,7 @@ void intel_device_info_runtime_init(struct
> drm_i915_private *dev_priv)
>
> if (IS_GEN6(dev_priv) && intel_vtd_active()) {
> DRM_INFO("Disabling ppGTT for VT-d support\n");
> - info->ppgtt = INTEL_PPGTT_NONE;
> + runtime_info->ppgtt = INTEL_PPGTT_NONE;
Cunning, you see I grepped the patch for the wrong thing (thinking it
was just the markup). We could make it static, but that would devalue the
information stored by ppgtt.
The alternative plan:
- move the disabling ppgtt into aliasing setup
- tag the PD offsets in the error state with [none, aliasing, full]
Advantage: we don't need to worry about runtime_info.pggtt
Disadvantage: extra code to generate equiv of runtime_info.ppgtt for
debugging.
> }
>
> /* Initialize command stream timestamp frequency */
>
> And:
>
> @@ -1711,7 +1711,7 @@ int i915_gem_huge_page_mock_selftests(void)
> return -ENOMEM;
>
> /* Pretend to be a device which supports the 48b PPGTT */
> - mkwrite_device_info(dev_priv)->ppgtt = INTEL_PPGTT_FULL_4LVL;
> + dev_priv->runtime_info.ppgtt = INTEL_PPGTT_FULL_4LVL;
That can be made static, but drops out later anyway. And when we have
separate ppgtt mode and size, I think it should be static (certainly we
are unlikely to change the ppgtt_size at runtime).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915 pvmmio to improve GVTg performance
== Series Details ==
Series: i915 pvmmio to improve GVTg performance
URL : https://patchwork.freedesktop.org/series/52410/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9c2f6b34b1d3 drm/i915: introduced pv capability for vgpu
-:68: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible
side-effects?
#68: FILE: drivers/gpu/drm/i915/i915_drv.h:3877:
+#define PVMMIO_LEVEL_ENABLE(dev_priv, level) \
+ (intel_vgpu_active(dev_priv) && intel_vgpu_has_pvmmio(dev_priv) \
+ && (dev_priv->vgpu.pv_caps & level))
-:68: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'level' may be better as
'(level)' to avoid precedence issues
#68: FILE: drivers/gpu/drm/i915/i915_drv.h:3877:
+#define PVMMIO_LEVEL_ENABLE(dev_priv, level) \
+ (intel_vgpu_active(dev_priv) && intel_vgpu_has_pvmmio(dev_priv) \
+ && (dev_priv->vgpu.pv_caps & level))
-:70: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
previous line
#70: FILE: drivers/gpu/drm/i915/i915_drv.h:3879:
+ (intel_vgpu_active(dev_priv) && intel_vgpu_has_pvmmio(dev_priv) \
+ && (dev_priv->vgpu.pv_caps & level))
-:139: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#139: FILE: drivers/gpu/drm/i915/i915_vgpu.c:94:
+ __raw_i915_write32(dev_priv, vgtif_reg(pvmmio_caps),
+ dev_priv->vgpu.pv_caps);
-:143: CHECK:LINE_SPACING: Please don't use multiple blank lines
#143: FILE: drivers/gpu/drm/i915/i915_vgpu.c:98:
+
+
-:145: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#145: FILE: drivers/gpu/drm/i915/i915_vgpu.c:100:
+ DRM_INFO("Virtual GPU for Intel GVT-g detected with pvmmio 0x%x\n",
+ dev_priv->vgpu.pv_caps);
total: 0 errors, 0 warnings, 6 checks, 97 lines checked
26121d00d625 drm/i915: get ready of memory for pvmmio
-:56: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#56: FILE: drivers/gpu/drm/i915/i915_drv.h:1356:
+ spinlock_t shared_page_lock;
-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/i915/i915_vgpu.c:107:
+ __raw_i915_write32(dev_priv, vgtif_reg(shared_page_gpa.lo),
+ lower_32_bits(gpa));
-:145: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#145: FILE: drivers/gpu/drm/i915/i915_vgpu.c:109:
+ __raw_i915_write32(dev_priv, vgtif_reg(shared_page_gpa.hi),
+ upper_32_bits(gpa));
-:147: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#147: FILE: drivers/gpu/drm/i915/i915_vgpu.c:111:
+ if (gpa != __raw_i915_read64(dev_priv,
+ vgtif_reg(shared_page_gpa))) {
-:155: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#155: FILE: drivers/gpu/drm/i915/i915_vgpu.c:119:
+ __raw_i915_write32(dev_priv, vgtif_reg(g2v_notify),
+ VGT_G2V_SHARED_PAGE_SETUP);
total: 0 errors, 0 warnings, 5 checks, 103 lines checked
544deaecea2e drm/i915: context submission pvmmio optimization
-:73: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#73: FILE: drivers/gpu/drm/i915/intel_lrc.c:407:
+static inline void write_desc(struct intel_engine_cs *engine,
+ u64 desc, u32 port)
-:84: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#84: FILE: drivers/gpu/drm/i915/intel_lrc.c:420:
+static inline void write_desc_pv(struct intel_engine_cs *engine,
+ u64 desc, u32 port)
-:96: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#96: FILE: drivers/gpu/drm/i915/intel_lrc.c:432:
+ __raw_i915_write32(dev_priv, vgtif_reg(g2v_notify),
+ VGT_G2V_ELSP_SUBMIT);
-:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#146: FILE: drivers/gpu/drm/i915/intel_ringbuffer.h:527:
+ void(*write_desc)(struct intel_engine_cs *engine,
+ u64 desc, u32 port);
total: 0 errors, 0 warnings, 4 checks, 89 lines checked
2f13c56ed4a4 drm/i915: ppgtt update pvmmio optimization
-:41: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
previous line
#41: FILE: drivers/gpu/drm/i915/i915_gem.c:5538:
+ if ((intel_vgpu_active(dev_priv) && !intel_vgpu_has_huge_gtt(dev_priv))
+ || PVMMIO_LEVEL_ENABLE(dev_priv, PVMMIO_PPGTT_UPDATE))
-:54: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#54: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:956:
+static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm,
+ u64 start, u64 length)
-:80: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#80: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:1216:
+static void gen8_ppgtt_insert_4lvl_pv(struct i915_address_space *vm,
+
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915 pvmmio to improve GVTg performance
== Series Details == Series: i915 pvmmio to improve GVTg performance URL : https://patchwork.freedesktop.org/series/52410/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: introduced pv capability for vgpu -drivers/gpu/drm/i915/selftests/../i915_drv.h:3714:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3721:16: warning: expression using sizeof(void) Commit: drm/i915: get ready of memory for pvmmio -drivers/gpu/drm/i915/selftests/../i915_drv.h:3721:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3723:16: warning: expression using sizeof(void) Commit: drm/i915: context submission pvmmio optimization Okay! Commit: drm/i915: ppgtt update pvmmio optimization Okay! Commit: drm/i915/gvt: GVTg handle pvmmio_caps PVINFO register Okay! Commit: drm/i915/gvt: GVTg handle shared_page setup Okay! Commit: drm/i915/gvt: GVTg support context submission pvmmio optimization Okay! Commit: drm/i915/gvt: GVTg support ppgtt pvmmio optimization +./include/linux/slab.h:665:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:665:13: warning: call with no type! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/8] i915 pvmmio to improve GVTg performance
Quoting Xiaolin Zhang (2018-11-13 08:35:12) > To improve GVTg performance, it could reduce the mmio access trap > numbers within guest driver in some certain scenarios since mmio > access trap will introuduce vm exit/vm enter cost. This still looks merely like a proof-of-concept, and does not look like a complete proposal for a protocol to a shared micro-controller. Nor does it look like it will be extensible into such a protocol. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915 pvmmio to improve GVTg performance
== Series Details == Series: i915 pvmmio to improve GVTg performance URL : https://patchwork.freedesktop.org/series/52410/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5127 -> Patchwork_10811 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10811 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10811, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/52410/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10811: === IGT changes === Possible regressions igt@gem_close_race@basic-threads: fi-bsw-n3050: PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_10811 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_contexts: fi-icl-u: NOTRUN -> DMESG-FAIL (fdo#108569) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) igt@kms_pipe_crc_basic@read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#107362) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-byt-clapper: PASS -> INCOMPLETE (fdo#102657) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-glk-dsi: FAIL (fdo#108721) -> PASS +1 igt@gem_exec_suspend@basic-s4-devices: fi-glk-dsi: FAIL -> PASS igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-a: fi-byt-clapper: FAIL (fdo#107362) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-glk-dsi: FAIL (fdo#103375) -> PASS +3 fi-icl-u: INCOMPLETE (fdo#107713) -> PASS igt@pm_rpm@module-reload: fi-glk-dsi: INCOMPLETE (k.org#198133, fdo#103359) -> PASS +1 fdo#102657 https://bugs.freedesktop.org/show_bug.cgi?id=102657 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108569 https://bugs.freedesktop.org/show_bug.cgi?id=108569 fdo#108721 https://bugs.freedesktop.org/show_bug.cgi?id=108721 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (51 -> 46) == Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_5127 -> Patchwork_10811 CI_DRM_5127: 31b5aaa2364ba86baf1293c69c5dcab446ef3a0e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10811: c3aa9b70d559e5edb4923aec38ed8c85fcbf10ec @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c3aa9b70d559 drm/i915/gvt: GVTg support ppgtt pvmmio optimization 19f7d5f0f66d drm/i915/gvt: GVTg support context submission pvmmio optimization 94f6273822da drm/i915/gvt: GVTg handle shared_page setup a10129739054 drm/i915/gvt: GVTg handle pvmmio_caps PVINFO register 2f13c56ed4a4 drm/i915: ppgtt update pvmmio optimization 544deaecea2e drm/i915: context submission pvmmio optimization 26121d00d625 drm/i915: get ready of memory for pvmmio 9c2f6b34b1d3 drm/i915: introduced pv capability for vgpu == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10811/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Return immediately if trylock fails for direct-reclaim
On 09/11/2018 11:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-11-09 07:30:34)
On 08/11/2018 16:48, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-11-08 16:23:08)
On 08/11/2018 08:17, Chris Wilson wrote:
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The proviso being that we still keep trying to hard
obtain the lock for oom so that we can reap under heavy memory pressure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index ea90d3a0d511..d461f458f4af 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -36,7 +36,9 @@
#include "i915_drv.h"
#include "i915_trace.h"
-static bool shrinker_lock(struct drm_i915_private *i915, bool *unlock)
+static bool shrinker_lock(struct drm_i915_private *i915,
+ unsigned int flags,
+ bool *unlock)
{
switch (mutex_trylock_recursive(&i915->drm.struct_mutex)) {
case MUTEX_TRYLOCK_RECURSIVE:
@@ -45,15 +47,11 @@ static bool shrinker_lock(struct drm_i915_private *i915,
bool *unlock)
case MUTEX_TRYLOCK_FAILED:
*unlock = false;
- preempt_disable();
- do {
- cpu_relax();
- if (mutex_trylock(&i915->drm.struct_mutex)) {
- *unlock = true;
- break;
- }
- } while (!need_resched());
- preempt_enable();
+ if (flags & I915_SHRINK_ACTIVE) {
So until I915_SHRINK_ACTIVE, which is the last ditch attempt to shrink
in the normal case (direct reclaim?) or oom, we bail out on the first
sign of struct mutex contention. Doesn't this make our shrinker much
less effective at runtime and why is that OK?
As I said, it's a tradeoff between blocking others for _several_
_seconds_ and making no progress and returning immediately and making no
progress. My argument is along the lines of if direct-reclaim is running
in another process and something else is engaged in the driver hopefully
the driver will be cleaning up as it goes along or else what remains is
active and won't be reaped anyway. If direct reclaim is failing, the
delay before trying the oom path is insignificant.
What was the rationale behind busy looping there btw?
Emulating the optimistic spin for mutex (my patches to expose it from
kernel/locking were kept hidden for public decency). My thinking was the
exact opposite to this patch, that direct reclaim was of paramount
importance and spending the time to try and ensure we grabbed the
struct_mutex to search for some pages to free was preferable.
It's just on the basis of looking at the actual syslatency and realising
the cause is this spinner, I want to swing the axe in other direction.
(There's probably a compromise, but honestly I'd prefer to sell the
struct_mutex free version of the shrinker first :)
Compared to
perhaps an alternative of micro-sleeps and trying a few times? I know it
would be opposite from what this patch is trying to achieve, I Just
don't had a good judgment on what makes most sense for the shrinker. Is
it better to perhaps try a little bit harder instead of giving up
immediately, but try a little bit harder in a softer way? Or that ends
up blocking the callers and has the same effect of making no progress?
Exactly. We can definitely measure the impact of the spinner on
unrelated processes, but detecting the premature allocation failure is
harder (we wait for more dmesg-warns). The compromise that I've tried to
reach here is that if direct-reclaim isn't enough, then we should still
try hard to grab the struct_mutex. (That leaves __GFP_RETRY_MAYFAIL
vulnerable to not shrinking i915, but a worthwhile compromise as it's
allowed to fail?)
Or in other words, for what use cases, tests or benchmark was the
existing approach of busy looping a problem?
Do something like 'find / -exec cat' while running i915 and see how long
you have to wait for a khungtaskd :|
I couldn't reproduce anything strange with this. Assuming you meant
something like -exec cat { } \; >dev/null.
Either case I think explanations like this should go into the commit
message.
Weird, I spent so long over the last few weeks talking about the impact
on gem_syslatency, I thought it was mentioned here.
gem_syslatency reports max latencies of over 600s, and I'm sure it's
pretty much unbounded. It's bad enough that I expect we are the cause of
significant hitching (mainly in othe
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v2)
On Mon, 12 Nov 2018, Guang Bai wrote: > Actually I'm still working on it right now with > DRM_MODE_CONNECTOR_HDMIA/HDMIB, recommended by James, I'm able to > differentiate the HDMI or DP even the encoder type is the > "INTEL_OUTPUT_DDI", I still have the "trybot" intermittent test failures > with new DRM connector types. Even worse, there is phantom > "intel_encoder_hotplug()" call following the correct one: > When connecting both DP and HDMI on the platform, unplug the DP, the > "i915_hotplug_work_func()" first calls the "intel_encoder_hotplug()" > with DP encoder, then calls again with HDMI encoder. > I haven't identified if the work function get queued twice or itself > is incorrectly identifying wrong encoder hotplut status. Will try to > get everything cleaned up ASAP. Frankly I liked the simplicity of [1] over the patch in this thread. It fixed the real-world use case Chris Chiu has, but I understand that it still failed the slow unplug HDMI test case you have. The problem is, we have zero visibility to the test case you have. Is it automated or manual? Can we see the specs or source code for the test case? If we have to consider the live status unreliable, it's possible to devise a pathological test case that will always fail, regardless of what we do in the driver. Does the test case reflect real world usage? Also Cc: Ville for input. BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/20180925071836.24711-1-jani.nik...@intel.com -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix plane allocation/free functions
== Series Details == Series: drm/i915: Fix plane allocation/free functions URL : https://patchwork.freedesktop.org/series/52413/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5129 -> Patchwork_10812 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10812 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10812, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/52413/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10812: === IGT changes === Warnings igt@drv_selftest@live_execlists: fi-icl-u2: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_10812 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) +1 Possible fixes igt@drv_module_reload@basic-reload: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-bsw-kefka: DMESG-WARN -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-hsw-4770r: DMESG-WARN (fdo#105602) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS Warnings igt@drv_selftest@live_contexts: fi-icl-u2: DMESG-FAIL (fdo#108569) -> INCOMPLETE (fdo#108315) fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108315 https://bugs.freedesktop.org/show_bug.cgi?id=108315 fdo#108569 https://bugs.freedesktop.org/show_bug.cgi?id=108569 == Participating hosts (51 -> 47) == Additional (1): fi-byt-j1900 Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_5129 -> Patchwork_10812 CI_DRM_5129: cbe30aefb2911ecac518064505b80cc7635ac6f8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10812: 4bd65ff95ef0b27ad4b064c5fe432191b131042f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4bd65ff95ef0 drm/i915: Fix plane allocation/free functions == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10812/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
On Tue, 13 Nov 2018, Tvrtko Ursulin wrote: > On 12/11/2018 17:25, Chris Wilson wrote: >> Quoting Tvrtko Ursulin (2018-11-12 17:12:39) >>> From: Tvrtko Ursulin >>> >>> Now that we are down to one caller, which does not even modify copied >>> device info, we can remove the mkwrite_device_info helper and convert the >>> device info pointer itself to be a pointer to static table instead of a >>> copy. >> >> The copy was deliberate to avoid the extra pointer. How does the change >> in code size now compare? > > AFAIR grows a bit, but overall series still ends up overall smaller. I > need to re-run the numbers for more concrete info. > > However, if we keep having a copy, ie. do not make device info properly > read-only, are we still interested in splitting the two? Benefit would > be diminished, but presumably people still think it would be worth it? If we don't turn device info into a pointer to the static const structs, IMO there's simply no point in any of this. Then we might just as well drop the const and mkwrite_device_info, and use the mutable thing all over the place. Modifying the device info copy was supposed to be an exception at the time of the copy, but with mkwrite_device_info it has proliferated. It's silly and ugly and wrong with no benefits. The const was put in place to hint that it's not supposed to be modified, but that didn't work out. So which is it, runtime/static split with an extra pointer chase to the const data in rodata (I'm in favor), or just drop the const from the dev_priv copy and remove mkwrite_device_info? The latter makes future attempts at utilizing DCE/LTO with a reduced number of device infos much harder I think. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 5/7] drm/i915: Move gen and platform mask to runtime device info
On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > It is more space efficient to store these two at the runtime copy since > both are trivially derived from the static data. Any consideration for potential future config option for reduced number of supported device infos, and compiler optimization on const gen? BR, Jani. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > Cc: Jani Nikula > --- > drivers/gpu/drm/i915/i915_drv.c | 15 + > drivers/gpu/drm/i915/i915_drv.h | 28 ++-- > drivers/gpu/drm/i915/i915_pci.c | 4 ++-- > drivers/gpu/drm/i915/intel_device_info.h | 6 ++--- > drivers/gpu/drm/i915/intel_uncore.c | 2 +- > 5 files changed, 33 insertions(+), 22 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 77dd7763b334..4f5ddc3d2f4d 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1657,10 +1657,6 @@ i915_driver_create(struct pci_dev *pdev, const struct > pci_device_id *ent) > i915->info = device_info = match_info; > pci_set_drvdata(pdev, &i915->drm); > > - BUILD_BUG_ON(INTEL_MAX_PLATFORMS > > - BITS_PER_TYPE(device_info->platform_mask)); > - BUG_ON(device_info->__gen > BITS_PER_TYPE(device_info->gen_mask)); > - > /* >* Early setup of the runtime device info. >*/ > @@ -1681,6 +1677,17 @@ i915_driver_create(struct pci_dev *pdev, const struct > pci_device_id *ent) > runtime_info->ring_mask = device_info->__ring_mask; > runtime_info->num_pipes = device_info->__num_pipes; > > + /* > + * Initialize GEN and platform masks. > + */ > + BUILD_BUG_ON(INTEL_MAX_PLATFORMS > > + BITS_PER_TYPE(runtime_info->platform_mask)); > + > + BUG_ON(INTEL_GEN(i915) > BITS_PER_TYPE(runtime_info->gen_mask)); > + > + runtime_info->gen_mask = BIT(INTEL_GEN(i915) - 1); > + runtime_info->platform_mask = BIT(device_info->platform); > + > return i915; > } > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 77ef41d53558..283592dd7023 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2365,7 +2365,7 @@ static inline unsigned int i915_sg_segment_size(void) > > /* Returns true if Gen is in inclusive range [Start, End] */ > #define IS_GEN(dev_priv, s, e) \ > - (!!(INTEL_INFO(dev_priv)->gen_mask & INTEL_GEN_MASK((s), (e > + (!!((dev_priv)->runtime_info.gen_mask & INTEL_GEN_MASK((s), (e > > /* > * Return true if revision is in range [since,until] inclusive. > @@ -2375,7 +2375,8 @@ static inline unsigned int i915_sg_segment_size(void) > #define IS_REVID(p, since, until) \ > (INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until)) > > -#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask & > BIT(p)) > +#define IS_PLATFORM(dev_priv, p) \ > + ((dev_priv)->runtime_info.platform_mask & BIT(p)) > > #define IS_I830(dev_priv)IS_PLATFORM(dev_priv, INTEL_I830) > #define IS_I845G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I845G) > @@ -2524,16 +2525,19 @@ static inline unsigned int i915_sg_segment_size(void) > * have their own (e.g. HAS_PCH_SPLIT for ILK+ display, IS_foo for particular > * chips, etc.). > */ > -#define IS_GEN2(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(1))) > -#define IS_GEN3(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(2))) > -#define IS_GEN4(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(3))) > -#define IS_GEN5(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(4))) > -#define IS_GEN6(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(5))) > -#define IS_GEN7(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(6))) > -#define IS_GEN8(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(7))) > -#define IS_GEN9(dev_priv)(!!(INTEL_INFO(dev_priv)->gen_mask & BIT(8))) > -#define IS_GEN10(dev_priv) (!!(INTEL_INFO(dev_priv)->gen_mask & BIT(9))) > -#define IS_GEN11(dev_priv) (!!(INTEL_INFO(dev_priv)->gen_mask & BIT(10))) > +#define __IS_GEN(dev_priv, g)\ > + (!!((dev_priv)->runtime_info.gen_mask & BIT((g) - 1))) > + > +#define IS_GEN2(dev_priv)__IS_GEN(dev_priv, 2) > +#define IS_GEN3(dev_priv)__IS_GEN(dev_priv, 3) > +#define IS_GEN4(dev_priv)__IS_GEN(dev_priv, 4) > +#define IS_GEN5(dev_priv)__IS_GEN(dev_priv, 5) > +#define IS_GEN6(dev_priv)__IS_GEN(dev_priv, 6) > +#define IS_GEN7(dev_priv)__IS_GEN(dev_priv, 7) > +#define IS_GEN8(dev_priv)__IS_GEN(dev_priv, 8) > +#define IS_GEN9(dev_priv)__IS_GEN(dev_priv, 9) > +#define IS_GEN10(dev_priv) __IS_GEN(dev_priv, 10) > +#define IS_GEN11(dev_priv) __IS_GEN(dev_priv, 11) > > #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp) > #define IS_GEN9_LP(dev_priv) (IS_GEN9(dev_priv) && IS_LP(dev_priv)) > diff --git a/drivers/gpu/drm/i915/i915_
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
Quoting Jani Nikula (2018-11-13 11:28:11) > On Tue, 13 Nov 2018, Tvrtko Ursulin wrote: > > On 12/11/2018 17:25, Chris Wilson wrote: > >> Quoting Tvrtko Ursulin (2018-11-12 17:12:39) > >>> From: Tvrtko Ursulin > >>> > >>> Now that we are down to one caller, which does not even modify copied > >>> device info, we can remove the mkwrite_device_info helper and convert the > >>> device info pointer itself to be a pointer to static table instead of a > >>> copy. > >> > >> The copy was deliberate to avoid the extra pointer. How does the change > >> in code size now compare? > > > > AFAIR grows a bit, but overall series still ends up overall smaller. I > > need to re-run the numbers for more concrete info. > > > > However, if we keep having a copy, ie. do not make device info properly > > read-only, are we still interested in splitting the two? Benefit would > > be diminished, but presumably people still think it would be worth it? > > If we don't turn device info into a pointer to the static const structs, > IMO there's simply no point in any of this. Then we might just as well > drop the const and mkwrite_device_info, and use the mutable thing all > over the place. > > Modifying the device info copy was supposed to be an exception at the > time of the copy, but with mkwrite_device_info it has proliferated. It's > silly and ugly and wrong with no benefits. The const was put in place to > hint that it's not supposed to be modified, but that didn't work out. > > So which is it, runtime/static split with an extra pointer chase to the > const data in rodata (I'm in favor), or just drop the const from the > dev_priv copy and remove mkwrite_device_info? > > The latter makes future attempts at utilizing DCE/LTO with a reduced > number of device infos much harder I think. The DCE goal is still worthwhile, as is making our constants truly immutable. It's just a digression as I remembered one benefit of the copy, and tracking how much of that benefit remains and could maybe recovered in other ways is something we can measure. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/7] drm/i915: Introduce subplatform concept
On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Introduce subplatform mask to eliminate throughout the code devid checking > sprinkle, mostly courtesy of IS_*_UL[TX] macros. > > Subplatform mask initialization is done at runtime device info init. I kind of like the concept, and I like the centralization of devid checks in one function, but I've always wanted to take this to one step further: only specify device ids in i915_pciids.h, and *nowhere* else. It's perhaps too much duplication to create a device info for all these variants, but I think it would be possible to make the subplatform info table driven using macros defined in i915_pciids.h. I think Rodrigo had patches to define CNL port F in terms of num_ports, but perhaps the subplatform approach works better for that. BR, Jani. > > v2: Fixed IS_SUBPLATFORM. Updated commit msg. > v3: Chris was right, there is an ordering problem. > v4: Drop mask sharing, rename title, rebase. > > Signed-off-by: Tvrtko Ursulin > Suggested-by: Chris Wilson > Cc: Chris Wilson > Cc: Jani Nikula > --- > drivers/gpu/drm/i915/i915_drv.c | 2 + > drivers/gpu/drm/i915/i915_drv.h | 59 + > drivers/gpu/drm/i915/intel_device_info.c | 65 > drivers/gpu/drm/i915/intel_device_info.h | 18 +++ > 4 files changed, 108 insertions(+), 36 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 4f5ddc3d2f4d..14c199438978 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1688,6 +1688,8 @@ i915_driver_create(struct pci_dev *pdev, const struct > pci_device_id *ent) > runtime_info->gen_mask = BIT(INTEL_GEN(i915) - 1); > runtime_info->platform_mask = BIT(device_info->platform); > > + intel_device_info_subplatform_init(i915); > + > return i915; > } > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 283592dd7023..4ec4a6308fe4 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2377,6 +2377,10 @@ static inline unsigned int i915_sg_segment_size(void) > > #define IS_PLATFORM(dev_priv, p) \ > ((dev_priv)->runtime_info.platform_mask & BIT(p)) > +#define IS_SUBPLATFORM(dev_priv, p, s) \ > + (IS_PLATFORM(dev_priv, p) && \ > + ((dev_priv)->runtime_info.subplatform_mask & \ > + BIT(INTEL_SUBPLATFORM_##s))) > > #define IS_I830(dev_priv)IS_PLATFORM(dev_priv, INTEL_I830) > #define IS_I845G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I845G) > @@ -2391,11 +2395,15 @@ static inline unsigned int i915_sg_segment_size(void) > #define IS_G45(dev_priv) IS_PLATFORM(dev_priv, INTEL_G45) > #define IS_GM45(dev_priv)IS_PLATFORM(dev_priv, INTEL_GM45) > #define IS_G4X(dev_priv) (IS_G45(dev_priv) || IS_GM45(dev_priv)) > -#define IS_PINEVIEW_G(dev_priv) (INTEL_DEVID(dev_priv) == 0xa001) > -#define IS_PINEVIEW_M(dev_priv) (INTEL_DEVID(dev_priv) == 0xa011) > +#define IS_PINEVIEW_G(dev_priv) \ > + IS_SUBPLATFORM(dev_priv, INTEL_PINEVIEW, PINEVIEW_G) > +#define IS_PINEVIEW_M(dev_priv) \ > + IS_SUBPLATFORM(dev_priv, INTEL_PINEVIEW, PINEVIEW_M) > #define IS_PINEVIEW(dev_priv)IS_PLATFORM(dev_priv, INTEL_PINEVIEW) > #define IS_G33(dev_priv) IS_PLATFORM(dev_priv, INTEL_G33) > -#define IS_IRONLAKE_M(dev_priv) (INTEL_DEVID(dev_priv) == 0x0046) > +#define IS_IRONLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_IRONLAKE) > +#define IS_IRONLAKE_M(dev_priv) \ > + IS_SUBPLATFORM(dev_priv, INTEL_IRONLAKE, IRONLAKE_M) > #define IS_IVYBRIDGE(dev_priv) IS_PLATFORM(dev_priv, INTEL_IVYBRIDGE) > #define IS_IVB_GT1(dev_priv) (IS_IVYBRIDGE(dev_priv) && \ >INTEL_INFO(dev_priv)->gt == 1) > @@ -2413,40 +2421,20 @@ static inline unsigned int i915_sg_segment_size(void) > #define IS_MOBILE(dev_priv) (INTEL_INFO(dev_priv)->is_mobile) > #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \ > (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00) > -#define IS_BDW_ULT(dev_priv) (IS_BROADWELL(dev_priv) && \ > - ((INTEL_DEVID(dev_priv) & 0xf) == 0x6 || > \ > - (INTEL_DEVID(dev_priv) & 0xf) == 0xb || > \ > - (INTEL_DEVID(dev_priv) & 0xf) == 0xe)) > -/* ULX machines are also considered ULT. */ > -#define IS_BDW_ULX(dev_priv) (IS_BROADWELL(dev_priv) && \ > - (INTEL_DEVID(dev_priv) & 0xf) == 0xe) > +#define IS_BDW_ULT(dev_priv) IS_SUBPLATFORM(dev_priv, INTEL_BROADWELL, ULT) > +#define IS_BDW_ULX(dev_priv) IS_SUBPLATFORM(dev_priv, INTEL_BROADWELL, ULX) > #define IS_BDW_GT3(dev_priv) (IS_BROADWELL(dev_priv) && \ >INTEL_INFO(dev_priv)->gt == 3) > -#define IS_HSW_ULT(dev_priv) (IS_HASWELL(dev_priv) && \ > - (IN
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
On Mon, 12 Nov 2018, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Now that we are down to one caller, which does not even modify copied
> device info, we can remove the mkwrite_device_info helper and convert the
> device info pointer itself to be a pointer to static table instead of a
> copy.
>
> Only unfortnate thing is that we need to convert all callsites which were
> referencing the device info directly to using the INTEL_INFO helper.
I'm not sure if that's all that bad. When I was toying around with
mkwrite_device_info removal, I actually started off with changing all
device info references to INTEL_INFO. It's a big patch, but it nicely
centralizes many of the other changes instead of splattering all over
the place.
I'd actually like to see RUNTIME_INFO or similar macro as well, just to
be able to change the way it's handled later on.
BR,
Jani.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.c | 9 +-
> drivers/gpu/drm/i915/i915_drv.h | 107 ++---
> drivers/gpu/drm/i915/i915_reg.h | 190 +++
> drivers/gpu/drm/i915/intel_device_info.c | 11 +-
> drivers/gpu/drm/i915/intel_device_info.h | 2 +-
> drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> 6 files changed, 151 insertions(+), 170 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bbdd36119eae..77dd7763b334 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1620,7 +1620,7 @@ static void i915_welcome_messages(struct
> drm_i915_private *dev_priv)
> if (drm_debug & DRM_UT_DRIVER) {
> struct drm_printer p = drm_debug_printer("i915 device info:");
>
> - intel_device_info_dump(&dev_priv->info, &p);
> + intel_device_info_dump(dev_priv, &p);
> intel_device_info_dump_runtime(&dev_priv->runtime_info, &p);
> }
>
> @@ -1638,7 +1638,7 @@ i915_driver_create(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> const struct intel_device_info *match_info =
> (struct intel_device_info *)ent->driver_data;
> struct intel_runtime_device_info *runtime_info;
> - struct intel_device_info *device_info;
> + const struct intel_device_info *device_info;
> struct drm_i915_private *i915;
> int err;
>
> @@ -1654,12 +1654,9 @@ i915_driver_create(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>
> i915->drm.pdev = pdev;
> i915->drm.dev_private = i915;
> + i915->info = device_info = match_info;
> pci_set_drvdata(pdev, &i915->drm);
>
> - /* Setup the write-once "constant" device info */
> - device_info = mkwrite_device_info(i915);
> - memcpy(device_info, match_info, sizeof(*device_info));
> -
> BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
>BITS_PER_TYPE(device_info->platform_mask));
> BUG_ON(device_info->__gen > BITS_PER_TYPE(device_info->gen_mask));
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4fabbcd6cfb2..77ef41d53558 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1588,7 +1588,7 @@ struct drm_i915_private {
> struct kmem_cache *dependencies;
> struct kmem_cache *priorities;
>
> - const struct intel_device_info info;
> + const struct intel_device_info *info;
> struct intel_runtime_device_info runtime_info;
> struct intel_driver_caps caps;
>
> @@ -2349,13 +2349,7 @@ static inline unsigned int i915_sg_segment_size(void)
> return size;
> }
>
> -static inline const struct intel_device_info *
> -intel_info(const struct drm_i915_private *dev_priv)
> -{
> - return &dev_priv->info;
> -}
> -
> -#define INTEL_INFO(dev_priv) intel_info((dev_priv))
> +#define INTEL_INFO(dev_priv) ((dev_priv)->info)
> #define DRIVER_CAPS(dev_priv)(&(dev_priv)->caps)
>
> #define INTEL_GEN(dev_priv) ((dev_priv)->runtime_info.gen)
> @@ -2371,7 +2365,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>
> /* Returns true if Gen is in inclusive range [Start, End] */
> #define IS_GEN(dev_priv, s, e) \
> - (!!((dev_priv)->info.gen_mask & INTEL_GEN_MASK((s), (e
> + (!!(INTEL_INFO(dev_priv)->gen_mask & INTEL_GEN_MASK((s), (e
>
> /*
> * Return true if revision is in range [since,until] inclusive.
> @@ -2381,7 +2375,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define IS_REVID(p, since, until) \
> (INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
>
> -#define IS_PLATFORM(dev_priv, p) ((dev_priv)->info.platform_mask & BIT(p))
> +#define IS_PLATFORM(dev_priv, p) (INTEL_INFO(dev_priv)->platform_mask &
> BIT(p))
>
> #define IS_I830(dev_priv)IS_PLATFORM(dev_priv, INTEL_I830)
> #define IS_I845G(dev_priv) IS_PLATFORM(dev_priv, INTEL_I845G)
> @@ -2403,7 +2397,7 @@ intel_info(const struct drm
Re: [Intel-gfx] [RFC 5/7] drm/i915: Move gen and platform mask to runtime device info
On 13/11/2018 11:30, Jani Nikula wrote: On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It is more space efficient to store these two at the runtime copy since both are trivially derived from the static data. Any consideration for potential future config option for reduced number of supported device infos, and compiler optimization on const gen? I of all people should have remember that detail! Thanks, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
On Tue, 13 Nov 2018, Jani Nikula wrote:
> On Mon, 12 Nov 2018, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> Now that we are down to one caller, which does not even modify copied
>> device info, we can remove the mkwrite_device_info helper and convert the
>> device info pointer itself to be a pointer to static table instead of a
>> copy.
>>
>> Only unfortnate thing is that we need to convert all callsites which were
>> referencing the device info directly to using the INTEL_INFO helper.
>
> I'm not sure if that's all that bad. When I was toying around with
> mkwrite_device_info removal, I actually started off with changing all
> device info references to INTEL_INFO. It's a big patch, but it nicely
> centralizes many of the other changes instead of splattering all over
> the place.
>
> I'd actually like to see RUNTIME_INFO or similar macro as well, just to
> be able to change the way it's handled later on.
Oh, and it would actually be possible to start off with a RUNTIME_INFO
macro that's just INTEL_INFO, and change all use sites of runtime info
first. Everything still pointing at the same place. Could then proceed
with a runtime copy, and then with actual splitting off of the structs.
Just food for thought, and definitely not a request to restructure the
series. But it might simplify some of the steps.
BR,
Jani.
>
> BR,
> Jani.
>
>
>>
>> Signed-off-by: Tvrtko Ursulin
>> Cc: Chris Wilson
>> Cc: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 9 +-
>> drivers/gpu/drm/i915/i915_drv.h | 107 ++---
>> drivers/gpu/drm/i915/i915_reg.h | 190 +++
>> drivers/gpu/drm/i915/intel_device_info.c | 11 +-
>> drivers/gpu/drm/i915/intel_device_info.h | 2 +-
>> drivers/gpu/drm/i915/intel_uncore.c | 2 +-
>> 6 files changed, 151 insertions(+), 170 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index bbdd36119eae..77dd7763b334 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -1620,7 +1620,7 @@ static void i915_welcome_messages(struct
>> drm_i915_private *dev_priv)
>> if (drm_debug & DRM_UT_DRIVER) {
>> struct drm_printer p = drm_debug_printer("i915 device info:");
>>
>> -intel_device_info_dump(&dev_priv->info, &p);
>> +intel_device_info_dump(dev_priv, &p);
>> intel_device_info_dump_runtime(&dev_priv->runtime_info, &p);
>> }
>>
>> @@ -1638,7 +1638,7 @@ i915_driver_create(struct pci_dev *pdev, const struct
>> pci_device_id *ent)
>> const struct intel_device_info *match_info =
>> (struct intel_device_info *)ent->driver_data;
>> struct intel_runtime_device_info *runtime_info;
>> -struct intel_device_info *device_info;
>> +const struct intel_device_info *device_info;
>> struct drm_i915_private *i915;
>> int err;
>>
>> @@ -1654,12 +1654,9 @@ i915_driver_create(struct pci_dev *pdev, const struct
>> pci_device_id *ent)
>>
>> i915->drm.pdev = pdev;
>> i915->drm.dev_private = i915;
>> +i915->info = device_info = match_info;
>> pci_set_drvdata(pdev, &i915->drm);
>>
>> -/* Setup the write-once "constant" device info */
>> -device_info = mkwrite_device_info(i915);
>> -memcpy(device_info, match_info, sizeof(*device_info));
>> -
>> BUILD_BUG_ON(INTEL_MAX_PLATFORMS >
>> BITS_PER_TYPE(device_info->platform_mask));
>> BUG_ON(device_info->__gen > BITS_PER_TYPE(device_info->gen_mask));
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 4fabbcd6cfb2..77ef41d53558 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1588,7 +1588,7 @@ struct drm_i915_private {
>> struct kmem_cache *dependencies;
>> struct kmem_cache *priorities;
>>
>> -const struct intel_device_info info;
>> +const struct intel_device_info *info;
>> struct intel_runtime_device_info runtime_info;
>> struct intel_driver_caps caps;
>>
>> @@ -2349,13 +2349,7 @@ static inline unsigned int i915_sg_segment_size(void)
>> return size;
>> }
>>
>> -static inline const struct intel_device_info *
>> -intel_info(const struct drm_i915_private *dev_priv)
>> -{
>> -return &dev_priv->info;
>> -}
>> -
>> -#define INTEL_INFO(dev_priv)intel_info((dev_priv))
>> +#define INTEL_INFO(dev_priv)((dev_priv)->info)
>> #define DRIVER_CAPS(dev_priv) (&(dev_priv)->caps)
>>
>> #define INTEL_GEN(dev_priv) ((dev_priv)->runtime_info.gen)
>> @@ -2371,7 +2365,7 @@ intel_info(const struct drm_i915_private *dev_priv)
>>
>> /* Returns true if Gen is in inclusive range [Start, End] */
>> #define IS_GEN(dev_priv, s, e) \
>> -(!!((dev_priv)->info.gen_mask & INTEL_GEN_MASK((s), (e
>> +(!!(INTEL_INFO(dev_priv)->gen_mask & INTEL_GEN_MASK((s), (e
>>
>> /*
>> * Return true if revision is
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
Quoting Jani Nikula (2018-11-13 11:45:02) > On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > Now that we are down to one caller, which does not even modify copied > > device info, we can remove the mkwrite_device_info helper and convert the > > device info pointer itself to be a pointer to static table instead of a > > copy. > > > > Only unfortnate thing is that we need to convert all callsites which were > > referencing the device info directly to using the INTEL_INFO helper. > > I'm not sure if that's all that bad. When I was toying around with > mkwrite_device_info removal, I actually started off with changing all > device info references to INTEL_INFO. It's a big patch, but it nicely > centralizes many of the other changes instead of splattering all over > the place. Fwiw, replacing all the static i915->info accesses with INTEL_INFO (or DEVICE_INFO since STATIC_INFO I think is too confusing with C, and INTEL_INFO is not distinct enough from RUNTIME_INFO) is perhaps a pre-requisite for single platform DCE. Along the lines of #define INTEL_INFO(i915) (&skylake_gt3_info) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 5/7] drm/i915: Move gen and platform mask to runtime device info
On 13/11/2018 11:48, Tvrtko Ursulin wrote: On 13/11/2018 11:30, Jani Nikula wrote: On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It is more space efficient to store these two at the runtime copy since both are trivially derived from the static data. Any consideration for potential future config option for reduced number of supported device infos, and compiler optimization on const gen? I of all people should have remember that detail! Remembered... but actually.. AFAIR the Kconfig platform/gen selection worked on the IS_xxx macro level so that would still work. It wasn't able to compile time optimize against the runtime device info copy anyway. So I think this does not interfere. Will keep it in mind. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/icl: reverse uninit order
On Mon, Nov 12, 2018 at 06:45:03PM -0800, Lucas De Marchi wrote:
> Bspec 21257 says "DDIA PHY is the comp master, so it must
> not be un-initialized if other combo PHYs are in use". Here
> we are shutting down all phys, so it's not strictly required.
> However let's be consistent on deinitializing things in the
> reversed order we initialized them.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_combo_phy.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
> b/drivers/gpu/drm/i915/intel_combo_phy.c
> index 49f3a533860d..9c06be45b84e 100644
> --- a/drivers/gpu/drm/i915/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/intel_combo_phy.c
> @@ -9,6 +9,12 @@
> for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
> for_each_if(intel_port_is_combophy(__dev_priv, __port))
>
> +#define for_each_combo_port_rev(__dev_priv, __port) \
> + for ((__port) = I915_MAX_PORTS - 1; \
> + (__port) >= PORT_A && (__port) < I915_MAX_PORTS; \
> + (__port)--) \
Heh, so 'enum port' is unsigned. Surely I would have get this right
only after seeing it fail with only the >= condition :) An
alternative:
for ((__port) = I915_MAX_PORTS; (__port)-- > 0;)
or add a negative value, like INVALID_PORT=-1 to 'enum port', but we'd
need some user for that too. Either way:
Reviewed-by: Imre Deak
> + for_each_if(intel_port_is_combophy(__dev_priv, __port))
> +
> enum {
> PROCMON_0_85V_DOT_0,
> PROCMON_0_95V_DOT_0,
> @@ -232,7 +238,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
> *dev_priv)
> {
> enum port port;
>
> - for_each_combo_port(dev_priv, port) {
> + for_each_combo_port_rev(dev_priv, port) {
> u32 val;
>
> if (!icl_combo_phy_verify_state(dev_priv, port))
> --
> 2.19.1.1.g56c4683e68
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/icl: reverse uninit order
On Tue, Nov 13, 2018 at 03:19:06PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:45:03PM -0800, Lucas De Marchi wrote:
> > Bspec 21257 says "DDIA PHY is the comp master, so it must
> > not be un-initialized if other combo PHYs are in use". Here
> > we are shutting down all phys, so it's not strictly required.
> > However let's be consistent on deinitializing things in the
> > reversed order we initialized them.
> >
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/intel_combo_phy.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
> > b/drivers/gpu/drm/i915/intel_combo_phy.c
> > index 49f3a533860d..9c06be45b84e 100644
> > --- a/drivers/gpu/drm/i915/intel_combo_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_combo_phy.c
> > @@ -9,6 +9,12 @@
> > for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
> > for_each_if(intel_port_is_combophy(__dev_priv, __port))
> >
> > +#define for_each_combo_port_rev(__dev_priv, __port) \
> > + for ((__port) = I915_MAX_PORTS - 1; \
> > +(__port) >= PORT_A && (__port) < I915_MAX_PORTS; \
> > +(__port)--) \
>
> Heh, so 'enum port' is unsigned. Surely I would have get this right
> only after seeing it fail with only the >= condition :) An
> alternative:
>
> for ((__port) = I915_MAX_PORTS; (__port)-- > 0;)
>
> or add a negative value, like INVALID_PORT=-1 to 'enum port', but we'd
Hm, actually we do have PORT_NONE=-1, in which case 'enum port' is a
signed int. So why do we need (__port) < I915_MAX_PORTS ?
> need some user for that too. Either way:
>
> Reviewed-by: Imre Deak
>
> > + for_each_if(intel_port_is_combophy(__dev_priv, __port))
> > +
> > enum {
> > PROCMON_0_85V_DOT_0,
> > PROCMON_0_95V_DOT_0,
> > @@ -232,7 +238,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
> > *dev_priv)
> > {
> > enum port port;
> >
> > - for_each_combo_port(dev_priv, port) {
> > + for_each_combo_port_rev(dev_priv, port) {
> > u32 val;
> >
> > if (!icl_combo_phy_verify_state(dev_priv, port))
> > --
> > 2.19.1.1.g56c4683e68
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix plane allocation/free functions
== Series Details == Series: drm/i915: Fix plane allocation/free functions URL : https://patchwork.freedesktop.org/series/52413/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5129_full -> Patchwork_10812_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10812_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@forcewake: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_schedule@pi-ringfull-bsd: shard-skl: NOTRUN -> FAIL (fdo#103158) igt@gem_exec_schedule@pi-ringfull-render: shard-apl: NOTRUN -> FAIL (fdo#103158) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-skl: NOTRUN -> FAIL (fdo#108470, fdo#108228) igt@kms_busy@extended-modeset-hang-newfb-render-b: shard-kbl: PASS -> DMESG-WARN (fdo#107956) igt@kms_busy@extended-pageflip-hang-newfb-render-b: shard-apl: NOTRUN -> DMESG-WARN (fdo#107956) igt@kms_cursor_crc@cursor-256x256-sliding: shard-apl: PASS -> FAIL (fdo#103232) igt@kms_cursor_crc@cursor-256x256-suspend: shard-apl: PASS -> FAIL (fdo#103191, fdo#103232) igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: shard-skl: NOTRUN -> FAIL (fdo#102670) igt@kms_draw_crc@draw-method-xrgb2101010-mmap-gtt-xtiled: shard-skl: PASS -> FAIL (fdo#103184) igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-cpu: shard-skl: PASS -> FAIL (fdo#105682) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt: shard-apl: PASS -> FAIL (fdo#103167) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: shard-glk: PASS -> FAIL (fdo#103167) igt@kms_frontbuffer_tracking@fbc-1p-rte: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +1 igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render: shard-skl: NOTRUN -> FAIL (fdo#103167) +3 igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen: shard-skl: NOTRUN -> FAIL (fdo#105682) igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-msflip-blt: shard-skl: PASS -> FAIL (fdo#103167) igt@kms_plane@pixel-format-pipe-c-planes: shard-skl: NOTRUN -> DMESG-WARN (fdo#106885) igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: shard-skl: PASS -> FAIL (fdo#103166) igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: shard-apl: NOTRUN -> FAIL (fdo#108145) igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: shard-skl: NOTRUN -> FAIL (fdo#108145) igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: shard-skl: PASS -> FAIL (fdo#108145, fdo#107815) igt@kms_plane_multiple@atomic-pipe-b-tiling-y: shard-apl: PASS -> FAIL (fdo#103166) igt@kms_plane_multiple@atomic-pipe-c-tiling-y: shard-glk: PASS -> FAIL (fdo#103166) igt@kms_properties@connector-properties-legacy: shard-kbl: PASS -> DMESG-WARN (fdo#103313, fdo#105345) igt@kms_rotation_crc@primary-rotation-90: shard-skl: NOTRUN -> FAIL (fdo#103925, fdo#107815) igt@pm_rpm@dpms-non-lpsp: shard-skl: SKIP -> INCOMPLETE (fdo#107807) Possible fixes igt@kms_busy@extended-pageflip-hang-newfb-render-a: shard-glk: DMESG-WARN (fdo#107956) -> PASS igt@kms_chv_cursor_fail@pipe-c-256x256-top-edge: shard-skl: FAIL (fdo#104671) -> PASS igt@kms_color@pipe-c-ctm-blue-to-red: shard-skl: FAIL (fdo#107201) -> PASS igt@kms_color@pipe-c-degamma: shard-apl: FAIL (fdo#104782) -> PASS igt@kms_cursor_crc@cursor-64x64-random: shard-apl: FAIL (fdo#103232) -> PASS igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: DMESG-WARN (fdo#105763, fdo#106538) -> PASS igt@kms_flip@flip-vs-modeset-vs-hang-interruptible: shard-apl: INCOMPLETE (fdo#103927) -> PASS +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite: shard-apl: FAIL (fdo#103167) -> PASS +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: shard-glk: FAIL (fdo#103167) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-render: shard-glk: DMESG-FAIL (fdo#106538) -> PASS igt@kms_plane_multiple@atomic-pipe-a-tiling-x: shard-apl: FAIL (fdo#103166) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS igt@pm_rpm@cursor-dpms: shard-skl: INCOMPLETE (fdo#107807) -> PASS Warnings igt@kms_vblank@pipe-
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/icl: replace check for combo phy
On Mon, Nov 12, 2018 at 06:45:02PM -0800, Lucas De Marchi wrote:
> These are the only places that assume ports A and B are the ones with
> combo phy. Let's use intel_port_is_combophy() there to make sure
> it checks for combo phy ports the same way everywhere.
>
> v2: define for_each_combo_port() helper to check the ports
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Imre Deak
> ---
>
> v2 of https://patchwork.freedesktop.org/series/52269/
>
> drivers/gpu/drm/i915/intel_combo_phy.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
> b/drivers/gpu/drm/i915/intel_combo_phy.c
> index f7c16f6724f0..49f3a533860d 100644
> --- a/drivers/gpu/drm/i915/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/intel_combo_phy.c
> @@ -5,6 +5,10 @@
>
> #include "intel_drv.h"
>
> +#define for_each_combo_port(__dev_priv, __port) \
> + for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
> + for_each_if(intel_port_is_combophy(__dev_priv, __port))
> +
> enum {
> PROCMON_0_85V_DOT_0,
> PROCMON_0_95V_DOT_0,
> @@ -199,7 +203,7 @@ void icl_combo_phys_init(struct drm_i915_private
> *dev_priv)
> {
> enum port port;
>
> - for (port = PORT_A; port <= PORT_B; port++) {
> + for_each_combo_port(dev_priv, port) {
> u32 val;
>
> if (icl_combo_phy_verify_state(dev_priv, port)) {
> @@ -228,7 +232,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
> *dev_priv)
> {
> enum port port;
>
> - for (port = PORT_A; port <= PORT_B; port++) {
> + for_each_combo_port(dev_priv, port) {
> u32 val;
>
> if (!icl_combo_phy_verify_state(dev_priv, port))
> --
> 2.19.1.1.g56c4683e68
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Drop spurious register read from icl_dbuf_slices_update
On Fri, Nov 09, 2018 at 04:09:23PM +0200, Mika Kuoppala wrote:
> Register DBUF_CTL_S2 is read and it's value is not used. As
> there is no explanation why we should prime the hardware with
> read, remove it as spurious.
>
> Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd DBuf slice only when needed")
> Cc: Mahesh Kumar
> Cc: Rodrigo Vivi
> Signed-off-by: Mika Kuoppala
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index f945db6ea420..770de2632530 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -3236,8 +3236,7 @@ static u8 intel_dbuf_max_slices(struct drm_i915_private
> *dev_priv)
> void icl_dbuf_slices_update(struct drm_i915_private *dev_priv,
> u8 req_slices)
> {
> - u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
> - u32 val;
> + const u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
> bool ret;
>
> if (req_slices > intel_dbuf_max_slices(dev_priv)) {
> @@ -3248,7 +3247,6 @@ void icl_dbuf_slices_update(struct drm_i915_private
> *dev_priv,
> if (req_slices == hw_enabled_slices || req_slices == 0)
> return;
>
> - val = I915_READ(DBUF_CTL_S2);
> if (req_slices > hw_enabled_slices)
> ret = intel_dbuf_slice_set(dev_priv, DBUF_CTL_S2, true);
> else
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix plane allocation/free functions
On Tue, Nov 13, 2018 at 10:28:04AM +0100, Maarten Lankhorst wrote:
> Use intel_plane_destroy_state in intel_plane_free to free the state.
Not entirely necessary since we have nothing in the state at that moment
that would required to be freed separately. But seems more future proof
anyway.
> Also fix intel_plane_alloc() to use __drm_atomic_helper_plane_reset(),
> to get sane defaults from the atomic core.
Could mention the constant alpha specifically here since I think it
was the only thing we didn't set ourselves.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Maarten Lankhorst
> Reported-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 40 ---
> drivers/gpu/drm/i915/intel_drv.h | 5 ++-
> drivers/gpu/drm/i915/intel_sprite.c | 29
> 3 files changed, 23 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 7d3685075201..905f8ef3ba4f 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -36,29 +36,31 @@
> #include
> #include "intel_drv.h"
>
> -/**
> - * intel_create_plane_state - create plane state object
> - * @plane: drm plane
> - *
> - * Allocates a fresh plane state for the given plane and sets some of
> - * the state values to sensible initial values.
> - *
> - * Returns: A newly allocated plane state, or NULL on failure
> - */
> -struct intel_plane_state *
> -intel_create_plane_state(struct drm_plane *plane)
> +struct intel_plane *intel_plane_alloc(void)
> {
> - struct intel_plane_state *state;
> + struct intel_plane_state *plane_state;
> + struct intel_plane *plane;
>
> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (!state)
> - return NULL;
> + plane = kzalloc(sizeof(*plane), GFP_KERNEL);
> + if (!plane)
> + return ERR_PTR(-ENOMEM);
>
> - state->base.plane = plane;
> - state->base.rotation = DRM_MODE_ROTATE_0;
> - state->scaler_id = -1;
> + plane_state = kzalloc(sizeof(*plane_state), GFP_KERNEL);
> + if (!plane_state) {
> + kfree(plane);
> + return ERR_PTR(-ENOMEM);
> + }
>
> - return state;
> + __drm_atomic_helper_plane_reset(&plane->base, &plane_state->base);
> + plane_state->scaler_id = -1;
> +
> + return plane;
> +}
> +
> +void intel_plane_free(struct intel_plane *plane)
> +{
> + intel_plane_destroy_state(&plane->base, plane->base.state);
> + kfree(plane);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 10a5df66e4eb..2a897e174ed5 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -2219,8 +2219,6 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state);
> int intel_plane_check_stride(const struct intel_plane_state *plane_state);
> int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state);
> int chv_plane_check_rotation(const struct intel_plane_state *plane_state);
> -struct intel_plane *intel_plane_alloc(void);
> -void intel_plane_free(struct intel_plane *plane);
> struct intel_plane *
> skl_universal_plane_create(struct drm_i915_private *dev_priv,
> enum pipe pipe, enum plane_id plane_id);
> @@ -2282,7 +2280,8 @@ int intel_atomic_setup_scalers(struct drm_i915_private
> *dev_priv,
> struct intel_crtc_state *crtc_state);
>
> /* intel_atomic_plane.c */
> -struct intel_plane_state *intel_create_plane_state(struct drm_plane *plane);
> +struct intel_plane *intel_plane_alloc(void);
> +void intel_plane_free(struct intel_plane *plane);
> struct drm_plane_state *intel_plane_duplicate_state(struct drm_plane *plane);
> void intel_plane_destroy_state(struct drm_plane *plane,
> struct drm_plane_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index facf7ca8f14f..7db6d060efe7 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1982,35 +1982,6 @@ static bool skl_plane_has_ccs(struct drm_i915_private
> *dev_priv,
>plane_id == PLANE_SPRITE0);
> }
>
> -struct intel_plane *intel_plane_alloc(void)
> -{
> - struct intel_plane_state *plane_state;
> - struct intel_plane *plane;
> -
> - plane = kzalloc(sizeof(*plane), GFP_KERNEL);
> - if (!plane)
> - return ERR_PTR(-ENOMEM);
> -
> - plane_state = intel_create_plane_state(&plane->base);
> - if (!plane_state) {
> - kfree(plane);
> - return ERR_PTR(-ENOMEM);
> - }
> -
> - plane->base.state = &plane_state->base;
> -
> - return plane;
> -}
> -
> -void intel_plane_free(struct intel_plan
[Intel-gfx] [PATCH v1] Fix the possible watermark miswriting
Currently whenever we attempt to recalculate watermarks, we assign dirty_pipes to zero, then compare current wm results to the recalculated one and if they changed we set correspondent dirty_pipes bit again. This can lead to situation, when we same clearing dirty_pipes, same wm results twice and not setting dirty_pipes => so that watermarks are not actually updated, which then might lead to fifo underruns, crc mismatch and other issues. Instead, whenever we detect that wm results are changed, need to set correspondent dirty_pipes bit and clear it only once the change is written, but not clear it everytime we attempt to recalculate those in skl_compute_wm. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_pm.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dc034617febb..f7fbc4bc0d43 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5441,9 +5441,6 @@ skl_compute_wm(struct drm_atomic_state *state) bool changed = false; int ret, i; - /* Clear all dirty flags */ - results->dirty_pipes = 0; - ret = skl_ddb_add_affected_pipes(state, &changed); if (ret || !changed) return ret; @@ -5496,6 +5493,7 @@ static void skl_atomic_update_crtc_wm(struct intel_atomic_state *state, struct drm_i915_private *dev_priv = to_i915(state->base.dev); struct skl_pipe_wm *pipe_wm = &cstate->wm.skl.optimal; const struct skl_ddb_allocation *ddb = &state->wm_results.ddb; + struct skl_ddb_values *results = &state->wm_results; enum pipe pipe = crtc->pipe; enum plane_id plane_id; @@ -5512,6 +5510,10 @@ static void skl_atomic_update_crtc_wm(struct intel_atomic_state *state, skl_write_cursor_wm(crtc, &pipe_wm->planes[plane_id], ddb); } + + /* Clear correspondent dirty bit */ + results->dirty_pipes &= ~drm_crtc_mask(&crtc->base); + } static void skl_initial_wm(struct intel_atomic_state *state, -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] Fix the possible watermark miswriting for skl+
Currently whenever we attempt to recalculate watermarks, we assign dirty_pipes to zero, then compare current wm results to the recalculated one and if they changed we set correspondent dirty_pipes bit again. This can lead to situation, when we are clearing dirty_pipes, same wm results twice in a row and not setting dirty_pipes => so that watermarks are not actually updated, which then might lead to fifo underruns, crc mismatch and other issues. Instead, whenever we detect that wm results are changed, need to set correspondent dirty_pipes bit and clear it only once the change is written, but not clear it everytime we attempt to recalculate those in skl_compute_wm. v2: Fixed commit message Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_pm.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dc034617febb..f7fbc4bc0d43 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5441,9 +5441,6 @@ skl_compute_wm(struct drm_atomic_state *state) bool changed = false; int ret, i; - /* Clear all dirty flags */ - results->dirty_pipes = 0; - ret = skl_ddb_add_affected_pipes(state, &changed); if (ret || !changed) return ret; @@ -5496,6 +5493,7 @@ static void skl_atomic_update_crtc_wm(struct intel_atomic_state *state, struct drm_i915_private *dev_priv = to_i915(state->base.dev); struct skl_pipe_wm *pipe_wm = &cstate->wm.skl.optimal; const struct skl_ddb_allocation *ddb = &state->wm_results.ddb; + struct skl_ddb_values *results = &state->wm_results; enum pipe pipe = crtc->pipe; enum plane_id plane_id; @@ -5512,6 +5510,10 @@ static void skl_atomic_update_crtc_wm(struct intel_atomic_state *state, skl_write_cursor_wm(crtc, &pipe_wm->planes[plane_id], ddb); } + + /* Clear correspondent dirty bit */ + results->dirty_pipes &= ~drm_crtc_mask(&crtc->base); + } static void skl_initial_wm(struct intel_atomic_state *state, -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] Per context dynamic (sub)slice power-gating
From: Tvrtko Ursulin Just a resend since almost two months have passed since the last one and there were some rebases needed due underlying code changes. Nothing major to warrant re-requesting the reviews, or in other words, the series is still fully reviewed. Lionel Landwerlin (2): drm/i915: Record the sseu configuration per-context & engine drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (4): drm/i915/execlists: Move RPCS setup to context pin drm/i915: Add timeline barrier support drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) drm/i915/icl: Support co-existence between per-context SSEU and OA drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_gem_context.c | 343 +- drivers/gpu/drm/i915/i915_gem_context.h | 10 + drivers/gpu/drm/i915/i915_perf.c | 13 +- drivers/gpu/drm/i915/i915_request.c | 13 + drivers/gpu/drm/i915/i915_request.h | 10 + drivers/gpu/drm/i915/i915_timeline.c | 3 + drivers/gpu/drm/i915/i915_timeline.h | 27 ++ drivers/gpu/drm/i915/intel_lrc.c | 100 +++-- drivers/gpu/drm/i915/intel_lrc.h | 2 + .../gpu/drm/i915/selftests/mock_timeline.c| 2 + include/uapi/drm/i915_drm.h | 43 +++ 12 files changed, 543 insertions(+), 37 deletions(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Record the sseu configuration per-context & engine
From: Lionel Landwerlin
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Tvrtko Ursulin:
v7:
* Pass intel_sseu by pointer instead of value to make_rpcs.
* Rebase for make_rpcs changes.
v8:
* Rebase for RPCS edit on pin.
v9:
* Rebase for context image setup changes.
v10:
* Rename dev_priv to i915. (Chris Wilson)
v11:
* Rebase.
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_gem_context.h | 4
drivers/gpu/drm/i915/i915_request.h | 10
drivers/gpu/drm/i915/intel_lrc.c| 31 +
5 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08d25aa480f7..6d5bf6173cd3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3471,6 +3471,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)&dev_priv->info;
}
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+ const struct sseu_dev_info *sseu = &INTEL_INFO(i915)->sseu;
+ struct intel_sseu value = {
+ .slice_mask = sseu->slice_mask,
+ .subslice_mask = sseu->subslice_mask[0],
+ .min_eus_per_subslice = sseu->max_eus_per_subslice,
+ .max_eus_per_subslice = sseu->max_eus_per_subslice,
+ };
+
+ return value;
+}
+
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b97963db0287..c8d09fdea49f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -343,6 +343,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = &ctx->__engine[n];
ce->gem_context = ctx;
+ /* Use the whole device by default */
+ ce->sseu = intel_device_default_sseu(dev_priv);
}
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index f6d870b1f73e..ef04e422cf9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
#include "i915_gem.h"
#include "i915_scheduler.h"
+#include "intel_device_info.h"
struct pid;
@@ -171,6 +172,9 @@ struct i915_gem_context {
int pin_count;
const struct intel_context_ops *ops;
+
+ /** sseu: Control eu/slice partitioning */
+ struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 90e9d170a0cd..07aaf9b43716 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,16 @@ struct drm_i915_gem_object;
struct i915_request;
struct i915_timeline;
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+ u8 slice_mask;
+ u8 subslice_mask;
+ u8 min_eus_per_subslice;
+ u8 max_eus_per_subslice;
+};
+
struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ab75088697a3..dc1e08b72446 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1152,7 +1152,8 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32 make_rpcs(struct drm_i915_private *dev_priv);
+static u32
+make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
@@ -1167,7 +1168,8 @@ __execlists_update_reg_state(struct intel_engine_cs
*engine,
/* R
[Intel-gfx] [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg =
{ .param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context (Chris)
v7: Synchronize the requests following a powergating setting change using a
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson
Signed-off-by: Lionel Landwerlin
Cc: Dmitry Rogozhkin
Cc: Tvrtko Ursulin
Cc: Zhipeng Gong
Cc: Joonas Lahtinen
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 341 +++-
drivers/gpu/drm/i915/i915_gem_context.h |
[Intel-gfx] [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin
From: Tvrtko Ursulin
Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.
v2:
* Split image setup a bit differently. (Chris Wilson)
v3:
* Update context image after reset as well - otherwise the application
of pinned default state clears the RPCS.
v4:
* Use local variable throughout the function. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 45
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 08fd9b12e4d7..ab75088697a3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1152,6 +1152,24 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
+static u32 make_rpcs(struct drm_i915_private *dev_priv);
+
+static void
+__execlists_update_reg_state(struct intel_engine_cs *engine,
+struct intel_context *ce)
+{
+ u32 *regs = ce->lrc_reg_state;
+ struct intel_ring *ring = ce->ring;
+
+ regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(ring->vma);
+ regs[CTX_RING_HEAD + 1] = ring->head;
+ regs[CTX_RING_TAIL + 1] = ring->tail;
+
+ /* RPCS */
+ if (engine->class == RENDER_CLASS)
+ regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915);
+}
+
static struct intel_context *
__execlists_context_pin(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
@@ -1190,10 +1208,8 @@ __execlists_context_pin(struct intel_engine_cs *engine,
GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
- ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
- i915_ggtt_offset(ce->ring->vma);
- ce->lrc_reg_state[CTX_RING_HEAD + 1] = ce->ring->head;
- ce->lrc_reg_state[CTX_RING_TAIL + 1] = ce->ring->tail;
+
+ __execlists_update_reg_state(engine, ce);
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
@@ -1803,14 +1819,14 @@ static void execlists_reset(struct intel_engine_cs
*engine,
engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
engine->context_size - PAGE_SIZE);
}
- execlists_init_reg_state(regs,
-request->gem_context, engine, request->ring);
/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
- regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
-
request->ring->head = intel_ring_wrap(request->ring, request->postfix);
- regs[CTX_RING_HEAD + 1] = request->ring->head;
+
+ execlists_init_reg_state(regs, request->gem_context, engine,
+request->ring);
+
+ __execlists_update_reg_state(engine, request->hw_context);
intel_ring_update_space(request->ring);
@@ -2560,8 +2576,7 @@ static void execlists_init_reg_state(u32 *regs,
if (rcs) {
regs[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
- CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
- make_rpcs(dev_priv));
+ CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE, 0);
i915_oa_init_reg_state(engine, ctx, regs);
}
@@ -2722,12 +2737,8 @@ void intel_lr_context_resume(struct drm_i915_private
*i915)
intel_ring_reset(ce->ring, 0);
- if (ce->pin_count) { /* otherwise done in context_pin */
- u32 *regs = ce->lrc_reg_state;
-
- regs[CTX_RING_HEAD + 1] = ce->ring->head;
- regs[CTX_RING_TAIL + 1] = ce->ring->tail;
- }
+ if (ce->pin_count) /* otherwise done in context_pin */
+ __execlists_update_reg_state(engine, ce);
}
}
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Add timeline barrier support
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
v2:
* Assert barrier has been retired on timeline_fini. (Chris Wilson)
* Fix mock_timeline.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 13 +
drivers/gpu/drm/i915/i915_timeline.c | 3 +++
drivers/gpu/drm/i915/i915_timeline.h | 27 +++
.../gpu/drm/i915/selftests/mock_timeline.c| 2 ++
4 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 71107540581d..d1b2ebfc0ff3 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -563,6 +563,15 @@ submit_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
return NOTIFY_DONE;
}
+static int add_timeline_barrier(struct i915_request *rq)
+{
+ struct i915_request *barrier =
+ i915_gem_active_raw(&rq->timeline->barrier,
+ &rq->i915->drm.struct_mutex);
+
+ return barrier ? i915_request_await_dma_fence(rq, &barrier->fence) : 0;
+}
+
/**
* i915_request_alloc - allocate a request structure
*
@@ -716,6 +725,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
+ ret = add_timeline_barrier(rq);
+ if (ret)
+ goto err_unwind;
+
/* Unconditionally invalidate GPU caches and TLBs. */
ret = engine->emit_flush(rq, EMIT_INVALIDATE);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 4667cc08c416..5a87c5bd5154 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -37,6 +37,8 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(&timeline->requests);
i915_syncmap_init(&timeline->sync);
+
+ init_request_active(&timeline->barrier, NULL);
}
/**
@@ -69,6 +71,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
void i915_timeline_fini(struct i915_timeline *timeline)
{
GEM_BUG_ON(!list_empty(&timeline->requests));
+ GEM_BUG_ON(i915_gem_active_isset(&timeline->barrier));
i915_syncmap_free(&timeline->sync);
diff --git a/drivers/gpu/drm/i915/i915_timeline.h
b/drivers/gpu/drm/i915/i915_timeline.h
index a2c2c3ab5fb0..c8526ab44dbc 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -72,6 +72,16 @@ struct i915_timeline {
*/
u32 global_sync[I915_NUM_ENGINES];
+ /**
+* Barrier provides the ability to serialize ordering between different
+* timelines.
+*
+* Users can call i915_timeline_set_barrier which will make all
+* subsequent submissions be executed only after this barrier has been
+* completed.
+*/
+ struct i915_gem_active barrier;
+
struct list_head link;
const char *name;
@@ -125,4 +135,21 @@ static inline bool i915_timeline_sync_is_later(struct
i915_timeline *tl,
void i915_timelines_park(struct drm_i915_private *i915);
+/**
+ * i915_timeline_set_barrier - orders submission between different timelines
+ * @timeline: timeline to set the barrier on
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions on @timeline. Subsequent requests will not be submitted to GPU
+ * until the barrier has been completed.
+ */
+static inline void
+i915_timeline_set_barrier(struct i915_timeline *timeline,
+ struct i915_request *rq)
+{
+ GEM_BUG_ON(timeline->fence_context == rq->timeline->fence_context);
+ i915_gem_active_set(&timeline->barrier, rq);
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index dcf3b16f5a07..a718b64c988e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -19,6 +19,8 @@ void mock_timeline_init(struct i915_timeline *timeline, u64
context)
i915_syncmap_init(&timeline->sync);
+ init_request_active(&timeline->barrier, NULL);
+
INIT_LIST_HEAD(&timeline->link);
}
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/perf: lock powergating configuration to default when active
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Tvrtko Ursulin:
v4:
* Rebase for make_rpcs changes.
v5:
* Apply OA restriction from make_rpcs directly.
v6:
* Rebase for context image setup changes.
v7:
* Move stream assignment before metric enable.
v8-9:
* Rebase.
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_perf.c | 13 +
drivers/gpu/drm/i915/intel_lrc.c | 31 ---
drivers/gpu/drm/i915/intel_lrc.h | 2 ++
3 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2c2b63be7a6c..627a83af2288 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1677,6 +1677,11 @@ static void gen8_update_reg_state_unlocked(struct
i915_gem_context *ctx,
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+ CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+ gen8_make_rpcs(dev_priv,
+ &to_intel_context(ctx,
+dev_priv->engine[RCS])->sseu));
}
/*
@@ -2098,21 +2103,21 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
if (ret)
goto err_lock;
+ stream->ops = &i915_oa_stream_ops;
+ dev_priv->perf.oa.exclusive_stream = stream;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(stream);
if (ret) {
DRM_DEBUG("Unable to enable metric set\n");
goto err_enable;
}
- stream->ops = &i915_oa_stream_ops;
-
- dev_priv->perf.oa.exclusive_stream = stream;
-
mutex_unlock(&dev_priv->drm.struct_mutex);
return 0;
err_enable:
+ dev_priv->perf.oa.exclusive_stream = NULL;
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index dc1e08b72446..ee02c593a72c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1152,9 +1152,6 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
}
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
-
static void
__execlists_update_reg_state(struct intel_engine_cs *engine,
struct intel_context *ce)
@@ -1168,8 +1165,8 @@ __execlists_update_reg_state(struct intel_engine_cs
*engine,
/* RPCS */
if (engine->class == RENDER_CLASS)
- regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915,
- &ce->sseu);
+ regs[CTX_R_PWR_CLK_STATE + 1] = gen8_make_rpcs(engine->i915,
+ &ce->sseu);
}
static struct intel_context *
@@ -2358,13 +2355,12 @@ int logical_xcs_ring_init(struct intel_engine_cs
*engine)
return logical_ring_init(engine);
}
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu)
+u32 gen8_make_rpcs(struct drm_
[Intel-gfx] [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA
From: Tvrtko Ursulin
When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.
Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.
v2:
* Fix commit message spelling.
v3:
Lionel:
* Add bspec reference.
* Fix spelling in comment.
Signed-off-by: Tvrtko Ursulin
Bspec: 21140
Cc: Lionel Landwerlin
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_lrc.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index bf3bb0460824..3b867f81f5b4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2372,13 +2372,28 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915,
struct intel_sseu *req_sseu)
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* on the system.
+*
+* We could choose full enablement, but on ICL we know there are use
+* cases which disable slices for functional, apart for performance
+* reasons. So in this case we select a known stable subset.
*/
- if (unlikely(i915->perf.oa.exclusive_stream))
- ctx_sseu = intel_device_default_sseu(i915);
- else
+ if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+ } else {
+ ctx_sseu = intel_device_default_sseu(i915);
+
+ if (IS_GEN11(i915)) {
+ /*
+* We only need subslice count so it doesn't matter
+* which ones we select - just turn off low bits in the
+* amount of half of all available subslices per slice.
+*/
+ ctx_sseu.subslice_mask =
+ ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
+ ctx_sseu.slice_mask = 0x1;
+ }
+ }
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/4] tests/gem_media_vme: Shut down half of subslices to avoid gpu hang on ICL
From: Tony Ye
On Icelake we need to turn off subslices not containing the VME block or
the VME kernel will hang.
v2: (Tvrtko Ursulin)
* Remove libdrm usage for setting context param.
* Cleanup bitmask operation.
* Only apply the workaround for ICL.
v3:
* Added hang detector. (Chris Wilson)
Signed-off-by: Tony Ye
Signed-off-by: Tvrtko Ursulin
---
lib/gpu_cmds.c | 12 +++
lib/gpu_cmds.h | 3 ++
lib/media_fill.c | 2 +-
tests/i915/gem_media_vme.c | 67 +-
4 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/lib/gpu_cmds.c b/lib/gpu_cmds.c
index b490a63bdfef..8d270ee86229 100644
--- a/lib/gpu_cmds.c
+++ b/lib/gpu_cmds.c
@@ -36,6 +36,18 @@ gen7_render_flush(struct intel_batchbuffer *batch, uint32_t
batch_end)
igt_assert(ret == 0);
}
+void
+gen7_render_context_flush(struct intel_batchbuffer *batch, uint32_t batch_end)
+{
+ int ret;
+
+ ret = drm_intel_bo_subdata(batch->bo, 0, 4096, batch->buffer);
+ if (ret == 0)
+ ret = drm_intel_gem_bo_context_exec(batch->bo, batch->ctx,
+ batch_end, 0);
+ igt_assert(ret == 0);
+}
+
uint32_t
gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
uint8_t color)
diff --git a/lib/gpu_cmds.h b/lib/gpu_cmds.h
index ca671fb52daf..1321af446161 100644
--- a/lib/gpu_cmds.h
+++ b/lib/gpu_cmds.h
@@ -40,6 +40,9 @@
void
gen7_render_flush(struct intel_batchbuffer *batch, uint32_t batch_end);
+void
+gen7_render_context_flush(struct intel_batchbuffer *batch, uint32_t batch_end);
+
uint32_t
gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
uint8_t color);
diff --git a/lib/media_fill.c b/lib/media_fill.c
index ab613b308742..d630f2785ae4 100644
--- a/lib/media_fill.c
+++ b/lib/media_fill.c
@@ -345,7 +345,7 @@ __gen11_media_vme_func(struct intel_batchbuffer *batch,
batch_end = intel_batchbuffer_align(batch, 8);
assert(batch_end < BATCH_STATE_SPLIT);
- gen7_render_flush(batch, batch_end);
+ gen7_render_context_flush(batch, batch_end);
intel_batchbuffer_reset(batch);
}
diff --git a/tests/i915/gem_media_vme.c b/tests/i915/gem_media_vme.c
index 1c2f33a45eb5..a8f7864621f7 100644
--- a/tests/i915/gem_media_vme.c
+++ b/tests/i915/gem_media_vme.c
@@ -81,6 +81,53 @@ static void scratch_buf_init_dst(drm_intel_bufmgr *bufmgr,
struct igt_buf *buf)
buf->stride = 1;
}
+static uint64_t switch_off_n_bits(uint64_t mask, unsigned int n)
+{
+ unsigned int i;
+
+ igt_assert(n > 0 && n <= (sizeof(mask) * 8));
+ igt_assert(n <= __builtin_popcount(mask));
+
+ for (i = 0; n && i < (sizeof(mask) * 8); i++) {
+ uint64_t bit = 1ULL << i;
+
+ if (bit & mask) {
+ mask &= ~bit;
+ n--;
+ }
+ }
+
+ return mask;
+}
+
+static void shut_non_vme_subslices(int drm_fd, uint32_t ctx)
+{
+ struct drm_i915_gem_context_param_sseu sseu = { };
+ struct drm_i915_gem_context_param arg =
+ {
+ .param = I915_CONTEXT_PARAM_SSEU,
+ .ctx_id = ctx,
+ .size = sizeof(sseu),
+ .value = to_user_pointer(&sseu),
+ };
+ int ret;
+
+ if (__gem_context_get_param(drm_fd, &arg))
+ return; /* no sseu support */
+
+ ret = __gem_context_set_param(drm_fd, &arg);
+ igt_assert(ret == 0 || ret == -ENODEV || ret == -EINVAL);
+ if (ret)
+ return; /* no sseu support */
+
+ /* shutdown half subslices*/
+ sseu.subslice_mask =
+ switch_off_n_bits(sseu.subslice_mask,
+ __builtin_popcount(sseu.subslice_mask) / 2);
+
+ gem_context_set_param(drm_fd, &arg);
+}
+
igt_simple_main
{
int drm_fd;
@@ -91,7 +138,7 @@ igt_simple_main
struct igt_buf src, dst;
uint8_t dst_linear[OUTPUT_SIZE];
- drm_fd = drm_open_driver_render(DRIVER_INTEL);
+ drm_fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(drm_fd);
devid = intel_get_drm_devid(drm_fd);
@@ -108,7 +155,25 @@ igt_simple_main
scratch_buf_init_src(bufmgr, &src);
scratch_buf_init_dst(bufmgr, &dst);
+ batch->ctx = drm_intel_gem_context_create(bufmgr);
+ igt_assert(batch->ctx);
+
+ /* ICL hangs if non-VME enabled slices are enabled with a VME kernel. */
+ if (intel_gen(devid) == 11) {
+ uint32_t ctx_id;
+ int ret;
+
+ ret = drm_intel_gem_context_get_id(batch->ctx, &ctx_id);
+ igt_assert_eq(ret, 0);
+
+ shut_non_vme_subslices(drm_fd, ctx_id);
+ }
+
+ igt_fork_hang_detector(drm_fd);
+
media_vme(batch, &src, WIDTH, HEIGHT, &dst);
gem_read(drm_fd, dst.bo->handle, 0,
dst_linear,
[Intel-gfx] [PATCH i-g-t 1/4] headers: bump
From: Lionel Landwerlin
---
include/drm-uapi/amdgpu_drm.h | 52 +++-
include/drm-uapi/drm.h | 17 ++
include/drm-uapi/drm_fourcc.h | 224 +++
include/drm-uapi/drm_mode.h| 26 +-
include/drm-uapi/etnaviv_drm.h | 6 +
include/drm-uapi/exynos_drm.h | 240
include/drm-uapi/i915_drm.h| 80 ++
include/drm-uapi/msm_drm.h | 2 +
include/drm-uapi/tegra_drm.h | 492 -
include/drm-uapi/v3d_drm.h | 204 ++
include/drm-uapi/vc4_drm.h | 13 +-
include/drm-uapi/virtgpu_drm.h | 1 +
include/drm-uapi/vmwgfx_drm.h | 166 ---
13 files changed, 1467 insertions(+), 56 deletions(-)
create mode 100644 include/drm-uapi/v3d_drm.h
diff --git a/include/drm-uapi/amdgpu_drm.h b/include/drm-uapi/amdgpu_drm.h
index 1816bd8200d1..370e9a5536ef 100644
--- a/include/drm-uapi/amdgpu_drm.h
+++ b/include/drm-uapi/amdgpu_drm.h
@@ -72,12 +72,41 @@ extern "C" {
#define DRM_IOCTL_AMDGPU_FENCE_TO_HANDLE DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FENCE_TO_HANDLE, union drm_amdgpu_fence_to_handle)
#define DRM_IOCTL_AMDGPU_SCHED DRM_IOW(DRM_COMMAND_BASE +
DRM_AMDGPU_SCHED, union drm_amdgpu_sched)
+/**
+ * DOC: memory domains
+ *
+ * %AMDGPU_GEM_DOMAIN_CPU System memory that is not GPU accessible.
+ * Memory in this pool could be swapped out to disk if there is pressure.
+ *
+ * %AMDGPU_GEM_DOMAIN_GTT GPU accessible system memory, mapped into the
+ * GPU's virtual address space via gart. Gart memory linearizes non-contiguous
+ * pages of system memory, allows GPU access system memory in a linezrized
+ * fashion.
+ *
+ * %AMDGPU_GEM_DOMAIN_VRAM Local video memory. For APUs, it is memory
+ * carved out by the BIOS.
+ *
+ * %AMDGPU_GEM_DOMAIN_GDS Global on-chip data storage used to share data
+ * across shader threads.
+ *
+ * %AMDGPU_GEM_DOMAIN_GWS Global wave sync, used to synchronize the
+ * execution of all the waves on a device.
+ *
+ * %AMDGPU_GEM_DOMAIN_OA Ordered append, used by 3D or Compute engines
+ * for appending data.
+ */
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
#define AMDGPU_GEM_DOMAIN_VRAM 0x4
#define AMDGPU_GEM_DOMAIN_GDS 0x8
#define AMDGPU_GEM_DOMAIN_GWS 0x10
#define AMDGPU_GEM_DOMAIN_OA 0x20
+#define AMDGPU_GEM_DOMAIN_MASK (AMDGPU_GEM_DOMAIN_CPU | \
+AMDGPU_GEM_DOMAIN_GTT | \
+AMDGPU_GEM_DOMAIN_VRAM | \
+AMDGPU_GEM_DOMAIN_GDS | \
+AMDGPU_GEM_DOMAIN_GWS | \
+AMDGPU_GEM_DOMAIN_OA)
/* Flag that CPU access will be required for the case of VRAM domain */
#define AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED (1 << 0)
@@ -95,6 +124,10 @@ extern "C" {
#define AMDGPU_GEM_CREATE_VM_ALWAYS_VALID (1 << 6)
/* Flag that BO sharing will be explicitly synchronized */
#define AMDGPU_GEM_CREATE_EXPLICIT_SYNC(1 << 7)
+/* Flag that indicates allocating MQD gart on GFX9, where the mtype
+ * for the second page onward should be set to NC.
+ */
+#define AMDGPU_GEM_CREATE_MQD_GFX9 (1 << 8)
struct drm_amdgpu_gem_create_in {
/** the requested memory size */
@@ -473,7 +506,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_HW_IP_UVD_ENC 5
#define AMDGPU_HW_IP_VCN_DEC 6
#define AMDGPU_HW_IP_VCN_ENC 7
-#define AMDGPU_HW_IP_NUM 8
+#define AMDGPU_HW_IP_VCN_JPEG 8
+#define AMDGPU_HW_IP_NUM 9
#define AMDGPU_HW_IP_INSTANCE_MAX_COUNT 1
@@ -482,6 +516,7 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_CHUNK_ID_DEPENDENCIES 0x03
#define AMDGPU_CHUNK_ID_SYNCOBJ_IN 0x04
#define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
+#define AMDGPU_CHUNK_ID_BO_HANDLES 0x06
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
@@ -520,6 +555,10 @@ union drm_amdgpu_cs {
/* Preempt flag, IB should set Pre_enb bit if PREEMPT flag detected */
#define AMDGPU_IB_FLAG_PREEMPT (1<<2)
+/* The IB fence should do the L2 writeback but not invalidate any shader
+ * caches (L2/vL1/sL1/I$). */
+#define AMDGPU_IB_FLAG_TC_WB_NOT_INVALIDATE (1 << 3)
+
struct drm_amdgpu_cs_chunk_ib {
__u32 _pad;
/** AMDGPU_IB_FLAG_* */
@@ -618,6 +657,16 @@ struct drm_amdgpu_cs_chunk_data {
#define AMDGPU_INFO_FW_SOS 0x0c
/* Subquery id: Query PSP ASD firmware version */
#define AMDGPU_INFO_FW_ASD 0x0d
+ /* Subquery id: Query VCN firmware version */
+ #define AMDGPU_INFO_FW_VCN 0x0e
+ /* Subquery id: Query GFX RLC SRLC firmware version */
+ #define AMDGPU_INFO_FW_GFX_RLC_RESTORE_LIST_CNTL 0x0f
+ /* Subquery id: Query GFX RLC SRLG firmware version */
+ #define AMDGPU_INFO_FW_GFX_RLC_RESTORE_LIST_GPM_MEM 0x10
+ /* Subquery id: Query GFX RL
[Intel-gfx] [PATCH i-g-t 2/4] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests
From: Lionel Landwerlin
Verify that the per-context dynamic SSEU uAPI works as expected.
To achieve that, in the absence of a better mechamism, we read the value
of PWR_CLK_STATE register, or use MI_SET_PREDICATE on platforms before
Cannonlake.
This register is written to by the GPU on context restore so this way
we verify i915 is correctly updating the context image in all
circumstances.
v2: Add subslice tests (Lionel)
Use MI_SET_PREDICATE for further verification when available (Lionel)
v3: Rename to gem_ctx_rpcs (Lionel)
v4: Update kernel API (Lionel)
Add 0 value test (Lionel)
Exercise invalid values (Lionel)
v5: Add perf tests (Lionel)
v6: Add new sysfs entry tests (Lionel)
v7: Test rsvd fields
Update for kernel series changes
v8: Drop test_no_sseu_support() test (Kelvin)
Drop drm_intel_*() apis (Chris)
v9: by Chris:
Drop all do_ioctl/do_ioctl_err()
Use gem_context_[gs]et_param()
Use gem_read() instead of mapping memory
by Lionel:
Test dynamic sseu on/off more
Tvrtko Ursulin:
v10:
* Various style tweaks and refactorings.
* New test coverage.
v11:
* Change platform support to just Gen11.
* Simplify availability test. (Chris Wilson)
* More invalid pointer tests. (Chris Wilson)
v12:
* Fix MAP_FIXED use (doh!).
* Fix get/set copy&paste errors.
* Drop supported platform test. (Chris Wilson)
* Add mmap__gtt test. (Chris Wilson)
v13:
* Commit message tweaks.
* Added reset/hang/suspend tests. (Chris Wilson)
* Assert spinner is busy. (Chris Wilson)
* Remove some more ABI assumptions. (Chris Wilson)
v14:
* Use default resume time. (Chris Wilson)
* Trigger hang after rpcs read batch has been submitted. (Chris Wilson)
v15:
* Adjust for uAPI restrictions.
v16:
* Build system changes.
Signed-off-by: Lionel Landwerlin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v14
---
tests/Makefile.am |1 +
tests/Makefile.sources |3 +
tests/i915/gem_ctx_param.c |4 +-
tests/i915/gem_ctx_sseu.c | 1190
tests/meson.build |8 +
5 files changed, 1205 insertions(+), 1 deletion(-)
create mode 100644 tests/i915/gem_ctx_sseu.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 3d1ce0bc1af8..79333ac7db26 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -109,6 +109,7 @@ gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_close_race_LDADD = $(LDADD) -lpthread
gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_ctx_thrash_LDADD = $(LDADD) -lpthread
+gem_ctx_sseu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
gem_exec_parallel_LDADD = $(LDADD) -lpthread
gem_fence_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c910210b992f..fd99bc15da67 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -159,6 +159,9 @@ gem_ctx_isolation_SOURCES = i915/gem_ctx_isolation.c
TESTS_progs += gem_ctx_param
gem_ctx_param_SOURCES = i915/gem_ctx_param.c
+TESTS_progs += gem_ctx_sseu
+gem_ctx_sseu_SOURCES = i915/gem_ctx_sseu.c
+
TESTS_progs += gem_ctx_switch
gem_ctx_switch_SOURCES = i915/gem_ctx_switch.c
diff --git a/tests/i915/gem_ctx_param.c b/tests/i915/gem_ctx_param.c
index c46fd709b0d7..af1afeaa2f2f 100644
--- a/tests/i915/gem_ctx_param.c
+++ b/tests/i915/gem_ctx_param.c
@@ -294,11 +294,13 @@ igt_main
set_priority(fd);
}
+ /* I915_CONTEXT_PARAM_SSEU tests are located in gem_ctx_sseu.c */
+
/* NOTE: This testcase intentionally tests for the next free parameter
* to catch ABI extensions. Don't "fix" this testcase without adding all
* the tests for the new param first.
*/
- arg.param = I915_CONTEXT_PARAM_PRIORITY + 1;
+ arg.param = I915_CONTEXT_PARAM_SSEU + 1;
igt_subtest("invalid-param-get") {
arg.ctx_id = ctx;
diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
new file mode 100644
index ..889f70643392
--- /dev/null
+++ b/tests/i915/gem_ctx_sseu.c
@@ -0,0 +1,1190 @@
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF M
[Intel-gfx] [PATCH i-g-t 0/4] Per context dynamic (sub)slice power-gating
From: Tvrtko Ursulin Tests to accompany the respective i915 series. Contributed by Tony Ye is gem_media_vme, anew test which exercises the media VME block to demonstrate the effectiveness of the uAPI for this particular issue. Lionel Landwerlin (2): headers: bump tests/gem_ctx_sseu: Dynamic (sub)slice programming tests Tony Ye (2): tests/gem_media_vme: Simple test to exercise the VME block tests/gem_media_vme: Shut down half of subslices to avoid gpu hang on ICL include/drm-uapi/amdgpu_drm.h | 52 +- include/drm-uapi/drm.h | 17 + include/drm-uapi/drm_fourcc.h | 224 ++ include/drm-uapi/drm_mode.h| 26 +- include/drm-uapi/etnaviv_drm.h |6 + include/drm-uapi/exynos_drm.h | 240 +++ include/drm-uapi/i915_drm.h| 80 +++ include/drm-uapi/msm_drm.h |2 + include/drm-uapi/tegra_drm.h | 492 - include/drm-uapi/v3d_drm.h | 204 ++ include/drm-uapi/vc4_drm.h | 13 +- include/drm-uapi/virtgpu_drm.h |1 + include/drm-uapi/vmwgfx_drm.h | 166 - lib/gpu_cmds.c | 148 lib/gpu_cmds.h | 23 +- lib/intel_batchbuffer.c|9 + lib/intel_batchbuffer.h|7 + lib/media_fill.c | 117 lib/media_fill.h |6 + lib/surfaceformat.h|2 + tests/Makefile.am |1 + tests/Makefile.sources |6 + tests/i915/gem_ctx_param.c |4 +- tests/i915/gem_ctx_sseu.c | 1190 tests/i915/gem_media_vme.c | 179 + tests/meson.build |9 + 26 files changed, 3165 insertions(+), 59 deletions(-) create mode 100644 include/drm-uapi/v3d_drm.h create mode 100644 tests/i915/gem_ctx_sseu.c create mode 100644 tests/i915/gem_media_vme.c -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/4] tests/gem_media_vme: Simple test to exercise the VME block
From: Tony Ye
Simple test which exercises the VME fixed function block.
v2: (Tvrtko Ursulin)
* Small cleanups like copyright date, tabs, remove unused bits.
v3: (Tony Ye)
* Added curbe data entry for dst surface.
* Read the dst surface after the VME kernel being executed.
Signed-off-by: Tony Ye
Signed-off-by: Tvrtko Ursulin
---
lib/gpu_cmds.c | 136 +
lib/gpu_cmds.h | 20 +-
lib/intel_batchbuffer.c| 9 +++
lib/intel_batchbuffer.h| 7 ++
lib/media_fill.c | 117 +++
lib/media_fill.h | 6 ++
lib/surfaceformat.h| 2 +
tests/Makefile.sources | 3 +
tests/i915/gem_media_vme.c | 114 +++
tests/meson.build | 1 +
10 files changed, 413 insertions(+), 2 deletions(-)
create mode 100644 tests/i915/gem_media_vme.c
diff --git a/lib/gpu_cmds.c b/lib/gpu_cmds.c
index 556a94c6f0b6..b490a63bdfef 100644
--- a/lib/gpu_cmds.c
+++ b/lib/gpu_cmds.c
@@ -52,6 +52,22 @@ gen7_fill_curbe_buffer_data(struct intel_batchbuffer *batch,
return offset;
}
+uint32_t
+gen11_fill_curbe_buffer_data(struct intel_batchbuffer *batch)
+{
+ uint32_t *curbe_buffer;
+ uint32_t offset;
+
+ curbe_buffer = intel_batchbuffer_subdata_alloc(batch,
+ sizeof(uint32_t) * 8,
+ 64);
+ offset = intel_batchbuffer_subdata_offset(batch, curbe_buffer);
+ *curbe_buffer++ = 0;
+ *curbe_buffer = 1;
+
+ return offset;
+}
+
uint32_t
gen7_fill_surface_state(struct intel_batchbuffer *batch,
const struct igt_buf *buf,
@@ -119,6 +135,26 @@ gen7_fill_binding_table(struct intel_batchbuffer *batch,
return offset;
}
+uint32_t
+gen11_fill_binding_table(struct intel_batchbuffer *batch,
+ const struct igt_buf *src,const struct igt_buf *dst)
+{
+ uint32_t *binding_table, offset;
+
+ binding_table = intel_batchbuffer_subdata_alloc(batch, 64, 64);
+ offset = intel_batchbuffer_subdata_offset(batch, binding_table);
+ binding_table[0] = gen11_fill_surface_state(batch, src,
+
SURFACE_1D,SURFACEFORMAT_R32G32B32A32_FLOAT,
+ 0,0,
+ 0);
+ binding_table[1] = gen11_fill_surface_state(batch, dst,
+ SURFACE_BUFFER,
SURFACEFORMAT_RAW,
+ 1,1,
+ 1);
+
+ return offset;
+}
+
uint32_t
gen7_fill_kernel(struct intel_batchbuffer *batch,
const uint32_t kernel[][4],
@@ -384,6 +420,71 @@ gen8_fill_surface_state(struct intel_batchbuffer *batch,
return offset;
}
+uint32_t
+gen11_fill_surface_state(struct intel_batchbuffer *batch,
+ const struct igt_buf *buf,
+ uint32_t surface_type,
+ uint32_t format,
+ uint32_t vertical_alignment,
+ uint32_t horizontal_alignment,
+ int is_dst)
+{
+ struct gen8_surface_state *ss;
+ uint32_t write_domain, read_domain, offset;
+ int ret;
+
+ if (is_dst) {
+ write_domain = read_domain = I915_GEM_DOMAIN_RENDER;
+ } else {
+ write_domain = 0;
+ read_domain = I915_GEM_DOMAIN_SAMPLER;
+ }
+
+ ss = intel_batchbuffer_subdata_alloc(batch, sizeof(*ss), 64);
+ offset = intel_batchbuffer_subdata_offset(batch, ss);
+
+ ss->ss0.surface_type = surface_type;
+ ss->ss0.surface_format = format;
+ ss->ss0.render_cache_read_write = 1;
+ ss->ss0.vertical_alignment = vertical_alignment; /* align 4 */
+ ss->ss0.horizontal_alignment = horizontal_alignment; /* align 4 */
+
+ if (buf->tiling == I915_TILING_X)
+ ss->ss0.tiled_mode = 2;
+ else if (buf->tiling == I915_TILING_Y)
+ ss->ss0.tiled_mode = 3;
+ else
+ ss->ss0.tiled_mode = 0;
+
+ ss->ss8.base_addr = buf->bo->offset;
+
+ ret = drm_intel_bo_emit_reloc(batch->bo,
+ intel_batchbuffer_subdata_offset(batch, ss) + 8
* 4,
+ buf->bo, 0, read_domain, write_domain);
+ igt_assert(ret == 0);
+
+ if (is_dst) {
+ ss->ss1.memory_object_control = 2;
+ ss->ss2.height = 1;
+ ss->ss2.width = 95;
+ ss->ss3.pitch = 0;
+ ss->ss7.shader_chanel_select_r = 4;
+ ss->ss7.shader_chanel_select_g = 5;
+ ss->ss7.shader_chanel_select_b = 6;
+ ss->ss7.shader_chanel_select_a = 7;
+ }
+ else {
+ ss->ss1.qpitch =
Re: [Intel-gfx] [PATCH v1] Fix the possible watermark miswriting
On Tue, Nov 13, 2018 at 04:27:28PM +0200, Stanislav Lisovskiy wrote: > Currently whenever we attempt to recalculate > watermarks, we assign dirty_pipes to zero, > then compare current wm results to the recalculated > one and if they changed we set correspondent dirty_pipes > bit again. > This can lead to situation, when we same clearing dirty_pipes, > same wm results twice and not setting dirty_pipes => so that > watermarks are not actually updated, which then might > lead to fifo underruns, crc mismatch and other issues. > > Instead, whenever we detect that wm results are changed, > need to set correspondent dirty_pipes bit and clear it > only once the change is written, but not clear it everytime > we attempt to recalculate those in skl_compute_wm. > > Signed-off-by: Stanislav Lisovskiy > --- > drivers/gpu/drm/i915/intel_pm.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index dc034617febb..f7fbc4bc0d43 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -5441,9 +5441,6 @@ skl_compute_wm(struct drm_atomic_state *state) > bool changed = false; > int ret, i; > > - /* Clear all dirty flags */ > - results->dirty_pipes = 0; > - > ret = skl_ddb_add_affected_pipes(state, &changed); > if (ret || !changed) > return ret; > @@ -5496,6 +5493,7 @@ static void skl_atomic_update_crtc_wm(struct > intel_atomic_state *state, > struct drm_i915_private *dev_priv = to_i915(state->base.dev); > struct skl_pipe_wm *pipe_wm = &cstate->wm.skl.optimal; > const struct skl_ddb_allocation *ddb = &state->wm_results.ddb; > + struct skl_ddb_values *results = &state->wm_results; > enum pipe pipe = crtc->pipe; > enum plane_id plane_id; > > @@ -5512,6 +5510,10 @@ static void skl_atomic_update_crtc_wm(struct > intel_atomic_state *state, > skl_write_cursor_wm(crtc, &pipe_wm->planes[plane_id], > ddb); > } > + > + /* Clear correspondent dirty bit */ > + results->dirty_pipes &= ~drm_crtc_mask(&crtc->base); > + > } Hmm. I can't figure out what the problem really is here. Yes, it does look like we'd end up writing the watermarks twice for pipes that are getting enabled. But that should be safeish (apart from the whole "need PLANE_SURF write to atually arm the update" mess). Note that this whole code is getting nuked soon (I hope): https://patchwork.freedesktop.org/series/51878/ but in the meantime if there is a clear bug we probably want the fix in first so that it can be backported. So I think we need a clear analysis of the actual problem. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix the possible watermark miswriting
== Series Details == Series: Fix the possible watermark miswriting URL : https://patchwork.freedesktop.org/series/52423/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5132 -> Patchwork_10813 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/52423/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10813 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 == Participating hosts (49 -> 44) == Additional (3): fi-byt-j1900 fi-glk-j4005 fi-kbl-7567u Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-elk-e7500 fi-icl-u == Build changes == * Linux: CI_DRM_5132 -> Patchwork_10813 CI_DRM_5132: 7fa49786320fddb8a4f89318e7eeb65ce6134f8b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10813: 4bd7c3cebd073fd0205cfa012293c97b2e9c5a51 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4bd7c3cebd07 Fix the possible watermark miswriting == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10813/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] Per context dynamic (sub)slice power-gating
Quoting Tvrtko Ursulin (2018-11-13 14:35:29) > From: Tvrtko Ursulin > > Just a resend since almost two months have passed since the last one and there > were some rebases needed due underlying code changes. > > Nothing major to warrant re-requesting the reviews, or in other words, the > series is still fully reviewed. And looks good. Nothing looked silly or out of place in re-reading the mechanics. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev7)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev7) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim checkpatch origin/drm-tip e5e9458e7692 drm/i915/execlists: Move RPCS setup to context pin 5c2565cbc409 drm/i915: Record the sseu configuration per-context & engine 111ba44372b7 drm/i915/perf: lock powergating configuration to default when active 519b5713792c drm/i915: Add timeline barrier support 6f3ff0f5558a drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) -:47: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #47: v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel) -:496: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'user->min_eus_per_subslice != device->max_eus_per_subslice' #496: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1175: + if ((user->min_eus_per_subslice != +device->max_eus_per_subslice) || + (user->max_eus_per_subslice != +device->max_eus_per_subslice)) -:496: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'user->max_eus_per_subslice != device->max_eus_per_subslice' #496: FILE: drivers/gpu/drm/i915/i915_gem_context.c:1175: + if ((user->min_eus_per_subslice != +device->max_eus_per_subslice) || + (user->max_eus_per_subslice != +device->max_eus_per_subslice)) total: 0 errors, 1 warnings, 2 checks, 479 lines checked d06e39a5d493 drm/i915/icl: Support co-existence between per-context SSEU and OA ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per context dynamic (sub)slice power-gating (rev7)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev7) URL : https://patchwork.freedesktop.org/series/48194/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Move RPCS setup to context pin Okay! Commit: drm/i915: Record the sseu configuration per-context & engine -drivers/gpu/drm/i915/selftests/../i915_drv.h:3714:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3728:16: warning: expression using sizeof(void) Commit: drm/i915/perf: lock powergating configuration to default when active Okay! Commit: drm/i915: Add timeline barrier support Okay! Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) +drivers/gpu/drm/i915/intel_lrc.c:2413:25: warning: expression using sizeof(void) Commit: drm/i915/icl: Support co-existence between per-context SSEU and OA Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix the possible watermark miswriting for skl+
== Series Details == Series: Fix the possible watermark miswriting for skl+ URL : https://patchwork.freedesktop.org/series/52425/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5132 -> Patchwork_10814 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/52425/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10814 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-bsw-kefka: PASS -> INCOMPLETE (fdo#108714) igt@gem_exec_suspend@basic-s3: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108714 https://bugs.freedesktop.org/show_bug.cgi?id=108714 == Participating hosts (49 -> 45) == Additional (3): fi-byt-j1900 fi-glk-j4005 fi-kbl-7567u Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_5132 -> Patchwork_10814 CI_DRM_5132: 7fa49786320fddb8a4f89318e7eeb65ce6134f8b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10814: 4b84e468f305112108e6b42d8fad677db4d7e5ca @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4b84e468f305 Fix the possible watermark miswriting for skl+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10814/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Per context dynamic (sub)slice power-gating (rev7)
== Series Details == Series: Per context dynamic (sub)slice power-gating (rev7) URL : https://patchwork.freedesktop.org/series/48194/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_5132 -> Patchwork_10815 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10815 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10815, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/48194/revisions/7/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10815: === IGT changes === Possible regressions igt@drv_selftest@live_contexts: fi-kbl-7560u: PASS -> INCOMPLETE Warnings igt@prime_vgem@basic-fence-flip: fi-hsw-4770:PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_10815 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cfl-8109u: PASS -> DMESG-WARN (fdo#107345) +2 Possible fixes igt@kms_chamelium@dp-crc-fast: fi-kbl-7500u: FAIL (fdo#108725) -> PASS +1 igt@kms_chamelium@dp-hpd-fast: fi-kbl-7500u: FAIL (fdo#108724) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS Warnings igt@kms_chamelium@common-hpd-after-suspend: fi-kbl-7500u: FAIL (fdo#108724) -> DMESG-WARN (fdo#105079, fdo#105602, fdo#102505) fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#105079 https://bugs.freedesktop.org/show_bug.cgi?id=105079 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108724 https://bugs.freedesktop.org/show_bug.cgi?id=108724 fdo#108725 https://bugs.freedesktop.org/show_bug.cgi?id=108725 == Participating hosts (49 -> 44) == Additional (3): fi-byt-j1900 fi-glk-j4005 fi-kbl-7567u Missing(8): fi-kbl-soraka fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_5132 -> Patchwork_10815 CI_DRM_5132: 7fa49786320fddb8a4f89318e7eeb65ce6134f8b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10815: d06e39a5d493e7d819ae89771bc4f47a8cc10023 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d06e39a5d493 drm/i915/icl: Support co-existence between per-context SSEU and OA 6f3ff0f5558a drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) 519b5713792c drm/i915: Add timeline barrier support 111ba44372b7 drm/i915/perf: lock powergating configuration to default when active 5c2565cbc409 drm/i915: Record the sseu configuration per-context & engine e5e9458e7692 drm/i915/execlists: Move RPCS setup to context pin == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10815/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Account for scale factor when calculating initial phase
On Fri, Nov 02, 2018 at 11:47:13AM +0200, Juha-Pekka Heikkila wrote:
> This seems to fix some DRM_FORMAT_RGB565 (up-)scaling IGT tests on on my
> KBL.
>
> Tested-by: Juha-Pekka Heikkila
Pushed with Maarten's irc r-b and t-b. Thanks for the review and
testing.
>
> On 29.10.2018 20:18, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To get the initial phase correct we need to account for the scale
> > factor as well. I forgot this initially and was mostly looking at
> > heavily upscaled content where the minor difference between -0.5
> > and the proper initial phase was not readily apparent.
> >
> > And let's toss in a comment that tries to explain the formula
> > a little bit.
> >
> > v2: The initial phase upper limit is 1.5, not 24.0!
> >
> > Cc: Maarten Lankhorst
> > Fixes: 0a59952b24e2 ("drm/i915: Configure SKL+ scaler initial phase
> > correctly")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 45 ++--
> > drivers/gpu/drm/i915/intel_drv.h | 2 +-
> > drivers/gpu/drm/i915/intel_sprite.c | 20 +
> > 3 files changed, 57 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index fe045abb6472..33dd2e9751e6 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4786,8 +4786,31 @@ static void cpt_verify_modeset(struct drm_device
> > *dev, int pipe)
> >* chroma samples for both of the luma samples, and thus we don't
> >* actually get the expected MPEG2 chroma siting convention :(
> >* The same behaviour is observed on pre-SKL platforms as well.
> > + *
> > + * Theory behind the formula (note that we ignore sub-pixel
> > + * source coordinates):
> > + * s = source sample position
> > + * d = destination sample position
> > + *
> > + * Downscaling 4:1:
> > + * -0.5
> > + * | 0.0
> > + * | | 1.5 (initial phase)
> > + * | | |
> > + * v v v
> > + * | s | s | s | s |
> > + * | d |
> > + *
> > + * Upscaling 1:4:
> > + * -0.5
> > + * | -0.375 (initial phase)
> > + * | | 0.0
> > + * | | |
> > + * v v v
> > + * | s |
> > + * | d | d | d | d |
> >*/
> > -u16 skl_scaler_calc_phase(int sub, bool chroma_cosited)
> > +u16 skl_scaler_calc_phase(int sub, int scale, bool chroma_cosited)
> > {
> > int phase = -0x8000;
> > u16 trip = 0;
> > @@ -4795,6 +4818,15 @@ u16 skl_scaler_calc_phase(int sub, bool
> > chroma_cosited)
> > if (chroma_cosited)
> > phase += (sub - 1) * 0x8000 / sub;
> >
> > + phase += scale / (2 * sub);
> > +
> > + /*
> > +* Hardware initial phase limited to [-0.5:1.5].
> > +* Since the max hardware scale factor is 3.0, we
> > +* should never actually excdeed 1.0 here.
> > +*/
> > + WARN_ON(phase < -0x8000 || phase > 0x18000);
> > +
> > if (phase < 0)
> > phase = 0x1 + phase;
> > else
> > @@ -5003,13 +5035,20 @@ static void skylake_pfit_enable(const struct
> > intel_crtc_state *crtc_state)
> >
> > if (crtc_state->pch_pfit.enabled) {
> > u16 uv_rgb_hphase, uv_rgb_vphase;
> > + int pfit_w, pfit_h, hscale, vscale;
> > int id;
> >
> > if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
> > return;
> >
> > - uv_rgb_hphase = skl_scaler_calc_phase(1, false);
> > - uv_rgb_vphase = skl_scaler_calc_phase(1, false);
> > + pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
> > + pfit_h = crtc_state->pch_pfit.size & 0x;
> > +
> > + hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
> > + vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
> > +
> > + uv_rgb_hphase = skl_scaler_calc_phase(1, hscale, false);
> > + uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
> >
> > id = scaler_state->scaler_id;
> > I915_WRITE(SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index db24308729b4..86d551a331b1 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1709,7 +1709,7 @@ void intel_mode_from_pipe_config(struct
> > drm_display_mode *mode,
> > void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
> > struct intel_crtc_state *crtc_state);
> >
> > -u16 skl_scaler_calc_phase(int sub, bool chroma_center);
> > +u16 skl_scaler_calc_phase(int sub, int scale, bool chroma_center);
> > int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state);
> > int skl_max_scale(const struct intel_crtc_state *crtc_state,
> > u32 pixel_format);
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index cfaddc05fea6..fbb916506c77 100644
> > --- a/driver
Re: [Intel-gfx] [PATCH] drm/i915: Always write both TILEOFF and LINOFF plane registers
On Thu, Nov 08, 2018 at 05:09:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Reduce the clutter in the sprite update functions by writing
> both TILEOFF and LINOFF registers unconditionally. We already
> did this for primary planes so might as well do it for the
> sprites too.
>
> There is no harm in writing both registers. Which one gets
> used depends on the tilimg mode selected in the plane control
> registers.
>
> It might even make sense to clear the register that won't
> get used. That could make register dumps a little easier to
> parse. But I'm not sure it's worth the extra hassle.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Ville Syrjälä
Pushed with Maarten's irc r-b.
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 1293182dbcb0..06e8845b071d 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -792,7 +792,6 @@ vlv_update_plane(struct intel_plane *plane,
>const struct intel_plane_state *plane_state)
> {
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - const struct drm_framebuffer *fb = plane_state->base.fb;
> enum pipe pipe = plane->pipe;
> enum plane_id plane_id = plane->id;
> u32 sprctl = plane_state->ctl;
> @@ -829,10 +828,8 @@ vlv_update_plane(struct intel_plane *plane,
> plane_state->color_plane[0].stride);
> I915_WRITE_FW(SPPOS(pipe, plane_id), (crtc_y << 16) | crtc_x);
>
> - if (fb->modifier == I915_FORMAT_MOD_X_TILED)
> - I915_WRITE_FW(SPTILEOFF(pipe, plane_id), (y << 16) | x);
> - else
> - I915_WRITE_FW(SPLINOFF(pipe, plane_id), linear_offset);
> + I915_WRITE_FW(SPTILEOFF(pipe, plane_id), (y << 16) | x);
> + I915_WRITE_FW(SPLINOFF(pipe, plane_id), linear_offset);
>
> I915_WRITE_FW(SPCONSTALPHA(pipe, plane_id), 0);
>
> @@ -950,7 +947,6 @@ ivb_update_plane(struct intel_plane *plane,
>const struct intel_plane_state *plane_state)
> {
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - const struct drm_framebuffer *fb = plane_state->base.fb;
> enum pipe pipe = plane->pipe;
> u32 sprctl = plane_state->ctl, sprscale = 0;
> u32 sprsurf_offset = plane_state->color_plane[0].offset;
> @@ -990,12 +986,12 @@ ivb_update_plane(struct intel_plane *plane,
>
> /* HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
>* register */
> - if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> + if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> I915_WRITE_FW(SPROFFSET(pipe), (y << 16) | x);
> - else if (fb->modifier == I915_FORMAT_MOD_X_TILED)
> + } else {
> I915_WRITE_FW(SPRTILEOFF(pipe), (y << 16) | x);
> - else
> I915_WRITE_FW(SPRLINOFF(pipe), linear_offset);
> + }
>
> I915_WRITE_FW(SPRSIZE(pipe), (crtc_h << 16) | crtc_w);
> if (IS_IVYBRIDGE(dev_priv))
> @@ -1119,7 +1115,6 @@ g4x_update_plane(struct intel_plane *plane,
>const struct intel_plane_state *plane_state)
> {
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> - const struct drm_framebuffer *fb = plane_state->base.fb;
> enum pipe pipe = plane->pipe;
> u32 dvscntr = plane_state->ctl, dvsscale = 0;
> u32 dvssurf_offset = plane_state->color_plane[0].offset;
> @@ -1157,10 +1152,8 @@ g4x_update_plane(struct intel_plane *plane,
> I915_WRITE_FW(DVSSTRIDE(pipe), plane_state->color_plane[0].stride);
> I915_WRITE_FW(DVSPOS(pipe), (crtc_y << 16) | crtc_x);
>
> - if (fb->modifier == I915_FORMAT_MOD_X_TILED)
> - I915_WRITE_FW(DVSTILEOFF(pipe), (y << 16) | x);
> - else
> - I915_WRITE_FW(DVSLINOFF(pipe), linear_offset);
> + I915_WRITE_FW(DVSTILEOFF(pipe), (y << 16) | x);
> + I915_WRITE_FW(DVSLINOFF(pipe), linear_offset);
>
> I915_WRITE_FW(DVSSIZE(pipe), (crtc_h << 16) | crtc_w);
> I915_WRITE_FW(DVSSCALE(pipe), dvsscale);
> --
> 2.18.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Fix the VLV/CHV DSI panel orientation hw readout
On Mon, Oct 22, 2018 at 09:41:36PM +0200, Hans de Goede wrote:
> Hi,
>
> On 22-10-18 16:19, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Let's make sure the DSI port is actually on before we go
> > poking at the plane register to determine which way
> > it's rotated. Otherwise we could be looking at a plane
> > that is feeding a HDMI port for instance.
> >
> > And in order to read the plane register we need the power
> > well to be on. Make sure that is indeed the case. We'll
> > also make sure the plane is actually enabled before we
> > trust the rotation bit to tell us the truth.
> >
> > v2: s/intel_dsi/vlv_dsi/
> >
> > Cc: Hans de Goede
> > Signed-off-by: Ville Syrjälä
>
> Ok, this series correctly detects the panel being upside-down
> on the BYT tablet with an upside down panel which I have, so
> this series is:
>
> Tested-by: Hans de Goede
>
> I assume that most tablets like this one will have the general->rotate_180
> bit set so that the firmware setup / EFI console will show up the right way
> up. So I think going ahead with this is fine.
Thanks. Pushed patch 1 and 2, with Maarten's irc r-b for patch 1.
I might leave patch 3 to sit for a while longer.
>
> Regards,
>
> Hans
>
>
>
>
> > ---
> > drivers/gpu/drm/i915/vlv_dsi.c | 56 ++
> > 1 file changed, 43 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
> > index ee0cd5d0bf91..dcc59f653e5b 100644
> > --- a/drivers/gpu/drm/i915/vlv_dsi.c
> > +++ b/drivers/gpu/drm/i915/vlv_dsi.c
> > @@ -1647,27 +1647,57 @@ static const struct drm_connector_funcs
> > intel_dsi_connector_funcs = {
> > .atomic_duplicate_state = intel_digital_connector_duplicate_state,
> > };
> >
> > -static int intel_dsi_get_panel_orientation(struct intel_connector
> > *connector)
> > +static enum drm_panel_orientation
> > +vlv_dsi_get_hw_panel_orientation(struct intel_connector *connector)
> > {
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > - int orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > - enum i9xx_plane_id i9xx_plane;
> > + struct intel_encoder *encoder = connector->encoder;
> > + enum intel_display_power_domain power_domain;
> > + enum drm_panel_orientation orientation;
> > + struct intel_plane *plane;
> > + struct intel_crtc *crtc;
> > + enum pipe pipe;
> > u32 val;
> >
> > - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > - if (connector->encoder->crtc_mask == BIT(PIPE_B))
> > - i9xx_plane = PLANE_B;
> > - else
> > - i9xx_plane = PLANE_A;
> > + if (!encoder->get_hw_state(encoder, &pipe))
> > + return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> >
> > - val = I915_READ(DSPCNTR(i9xx_plane));
> > - if (val & DISPPLANE_ROTATE_180)
> > - orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> > - }
> > + crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> > + plane = to_intel_plane(crtc->base.primary);
> > +
> > + power_domain = POWER_DOMAIN_PIPE(pipe);
> > + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> > + return DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > +
> > + val = I915_READ(DSPCNTR(plane->i9xx_plane));
> > +
> > + if (!(val & DISPLAY_PLANE_ENABLE))
> > + orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > + else if (val & DISPPLANE_ROTATE_180)
> > + orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> > + else
> > + orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > +
> > + intel_display_power_put(dev_priv, power_domain);
> >
> > return orientation;
> > }
> >
> > +static enum drm_panel_orientation
> > +vlv_dsi_get_panel_orientation(struct intel_connector *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + enum drm_panel_orientation orientation;
> > +
> > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > + orientation = vlv_dsi_get_hw_panel_orientation(connector);
> > + if (orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
> > + return orientation;
> > + }
> > +
> > + return DRM_MODE_PANEL_ORIENTATION_NORMAL;
> > +}
> > +
> > static void intel_dsi_add_properties(struct intel_connector *connector)
> > {
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > @@ -1685,7 +1715,7 @@ static void intel_dsi_add_properties(struct
> > intel_connector *connector)
> > connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
> >
> > connector->base.display_info.panel_orientation =
> > - intel_dsi_get_panel_orientation(connector);
> > + vlv_dsi_get_panel_orientation(connector);
> > drm_connector_init_panel_orientation_property(
> > &connector->b
Re: [Intel-gfx] [PATCH] drm/i915: Move skip_intermediate_wm handling into ilk_compute_intermediate_wm()
On Thu, Nov 08, 2018 at 05:10:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No point in cluttering the common codepaths with the
> skip_intermediate_wm handling. Just move it into
> ilk_compute_intermediate_wm() as those are the only
> platforms using this.
>
> Signed-off-by: Ville Syrjälä
Pushed with Maarten's irc r-b.
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 +--
> drivers/gpu/drm/i915/intel_pm.c | 3 ++-
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 71b7bff85e52..00e775f22a45 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10817,7 +10817,6 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc_state);
> - struct drm_atomic_state *state = crtc_state->state;
> int ret;
> bool mode_changed = needs_modeset(crtc_state);
>
> @@ -10854,8 +10853,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> }
> }
>
> - if (dev_priv->display.compute_intermediate_wm &&
> - !to_intel_atomic_state(state)->skip_intermediate_wm) {
> + if (dev_priv->display.compute_intermediate_wm) {
> if (WARN_ON(!dev_priv->display.compute_pipe_wm))
> return 0;
>
> @@ -10871,9 +10869,6 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> DRM_DEBUG_KMS("No valid intermediate pipe watermarks
> are possible\n");
> return ret;
> }
> - } else if (dev_priv->display.compute_intermediate_wm) {
> - if (HAS_PCH_SPLIT(dev_priv) && INTEL_GEN(dev_priv) < 9)
> - pipe_config->wm.ilk.intermediate =
> pipe_config->wm.ilk.optimal;
> }
>
> if (INTEL_GEN(dev_priv) >= 9) {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9da8ff263d36..2b57e360c043 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3159,7 +3159,8 @@ static int ilk_compute_intermediate_wm(struct
> drm_device *dev,
>* and after the vblank.
>*/
> *a = newstate->wm.ilk.optimal;
> - if (!newstate->base.active ||
> drm_atomic_crtc_needs_modeset(&newstate->base))
> + if (!newstate->base.active ||
> drm_atomic_crtc_needs_modeset(&newstate->base) ||
> + intel_state->skip_intermediate_wm)
> return 0;
>
> a->pipe_enabled |= b->pipe_enabled;
> --
> 2.18.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] Fix the possible watermark miswriting for skl+
Quoting Stanislav Lisovskiy (2018-11-13 14:31:38) > Currently whenever we attempt to recalculate > watermarks, we assign dirty_pipes to zero, > then compare current wm results to the recalculated > one and if they changed we set correspondent dirty_pipes > bit again. > This can lead to situation, when we are clearing dirty_pipes, > same wm results twice in a row and not setting dirty_pipes > => so that watermarks are not actually updated, which then might > lead to fifo underruns, crc mismatch and other issues. > > Instead, whenever we detect that wm results are changed, > need to set correspondent dirty_pipes bit and clear it > only once the change is written, but not clear it everytime > we attempt to recalculate those in skl_compute_wm. Ok, but are not dirty_pipes being recomputed for each commit wrt to the current HW state. Should dirty_pipes not be 0 at the start of compute_wm naturally due to it not being used before in the atomic commit sequence? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Return immediately if trylock fails for direct-reclaim
Quoting Tvrtko Ursulin (2018-11-13 10:24:43)
>
> On 09/11/2018 11:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-11-09 07:30:34)
> >>
> >> On 08/11/2018 16:48, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-11-08 16:23:08)
>
> On 08/11/2018 08:17, Chris Wilson wrote:
> > Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
> > in the shrinker while performing direct-reclaim. The trade-off being
> > (much) lower latency for non-i915 clients at an increased risk of being
> > unable to obtain a page from direct-reclaim without hitting the
> > oom-notifier. The proviso being that we still keep trying to hard
> > obtain the lock for oom so that we can reap under heavy memory pressure.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_gem_shrinker.c | 24
> > +++-
> > 1 file changed, 11 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > index ea90d3a0d511..d461f458f4af 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > @@ -36,7 +36,9 @@
> > #include "i915_drv.h"
> > #include "i915_trace.h"
> >
> > -static bool shrinker_lock(struct drm_i915_private *i915, bool *unlock)
> > +static bool shrinker_lock(struct drm_i915_private *i915,
> > + unsigned int flags,
> > + bool *unlock)
> > {
> > switch (mutex_trylock_recursive(&i915->drm.struct_mutex)) {
> > case MUTEX_TRYLOCK_RECURSIVE:
> > @@ -45,15 +47,11 @@ static bool shrinker_lock(struct drm_i915_private
> > *i915, bool *unlock)
> >
> > case MUTEX_TRYLOCK_FAILED:
> > *unlock = false;
> > - preempt_disable();
> > - do {
> > - cpu_relax();
> > - if (mutex_trylock(&i915->drm.struct_mutex)) {
> > - *unlock = true;
> > - break;
> > - }
> > - } while (!need_resched());
> > - preempt_enable();
> > + if (flags & I915_SHRINK_ACTIVE) {
>
> So until I915_SHRINK_ACTIVE, which is the last ditch attempt to shrink
> in the normal case (direct reclaim?) or oom, we bail out on the first
> sign of struct mutex contention. Doesn't this make our shrinker much
> less effective at runtime and why is that OK?
> >>>
> >>> As I said, it's a tradeoff between blocking others for _several_
> >>> _seconds_ and making no progress and returning immediately and making no
> >>> progress. My argument is along the lines of if direct-reclaim is running
> >>> in another process and something else is engaged in the driver hopefully
> >>> the driver will be cleaning up as it goes along or else what remains is
> >>> active and won't be reaped anyway. If direct reclaim is failing, the
> >>> delay before trying the oom path is insignificant.
> >>
> >> What was the rationale behind busy looping there btw?
> >
> > Emulating the optimistic spin for mutex (my patches to expose it from
> > kernel/locking were kept hidden for public decency). My thinking was the
> > exact opposite to this patch, that direct reclaim was of paramount
> > importance and spending the time to try and ensure we grabbed the
> > struct_mutex to search for some pages to free was preferable.
> >
> > It's just on the basis of looking at the actual syslatency and realising
> > the cause is this spinner, I want to swing the axe in other direction.
> >
> > (There's probably a compromise, but honestly I'd prefer to sell the
> > struct_mutex free version of the shrinker first :)
> >
> >> Compared to
> >> perhaps an alternative of micro-sleeps and trying a few times? I know it
> >> would be opposite from what this patch is trying to achieve, I Just
> >> don't had a good judgment on what makes most sense for the shrinker. Is
> >> it better to perhaps try a little bit harder instead of giving up
> >> immediately, but try a little bit harder in a softer way? Or that ends
> >> up blocking the callers and has the same effect of making no progress?
> >
> > Exactly. We can definitely measure the impact of the spinner on
> > unrelated processes, but detecting the premature allocation failure is
> > harder (we wait for more dmesg-warns). The compromise that I've tried to
> > reach here is that if direct-reclaim isn't enough, then we should still
> > try hard to grab the struct_mutex. (That leaves __GFP_RETRY_MAYFAIL
> > vulnerable to not shrinking i915, but a worthwhile compromise as it's
> > allowed to fail?)
> >
> Or in other words, for what use cases, tests or benchmark was the
> exi
Re: [Intel-gfx] [RFC 6/7] drm/i915: Introduce subplatform concept
On 13/11/2018 11:40, Jani Nikula wrote: On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Introduce subplatform mask to eliminate throughout the code devid checking sprinkle, mostly courtesy of IS_*_UL[TX] macros. Subplatform mask initialization is done at runtime device info init. I kind of like the concept, and I like the centralization of devid checks in one function, but I've always wanted to take this to one step further: only specify device ids in i915_pciids.h, and *nowhere* else. It's perhaps too much duplication to create a device info for all these variants, but I think it would be possible to make the subplatform info table driven using macros defined in i915_pciids.h. It would be much nicer, but how would you do it? Perhaps my imagination is just strong enough today. Simply by splitting the id's into subplatform parts, for instance where we have today: #define INTEL_BDW_GT1_IDS(info) \ INTEL_VGA_DEVICE(0x1602, info), /* GT1 ULT */ \ INTEL_VGA_DEVICE(0x1606, info), /* GT1 ULT */ \ INTEL_VGA_DEVICE(0x160B, info), /* GT1 Iris */ \ INTEL_VGA_DEVICE(0x160E, info), /* GT1 ULX */ \ INTEL_VGA_DEVICE(0x160A, info), /* GT1 Server */ \ INTEL_VGA_DEVICE(0x160D, info) /* GT1 Workstation */ We'd split to: #define INTEL_BDW_GT1_ULT_IDS(info) \ INTEL_VGA_DEVICE(0x1602, info), /* GT1 ULT */ \ INTEL_VGA_DEVICE(0x1606, info), /* GT1 ULT */ \ #define INTEL_BDW_GT1_ULX_IDS(info) \ INTEL_VGA_DEVICE(0x160E, info), /* GT1 ULX */ \ #define INTEL_BDW_GT1_IDS(info) \ INTEL_VGA_DEVICE(0x160B, info), /* GT1 Iris */ \ INTEL_VGA_DEVICE(0x160A, info), /* GT1 Server */ \ INTEL_VGA_DEVICE(0x160D, info) /* GT1 Workstation */ Then in i915_pci.c, instead of: ... INTEL_BDW_GT1_IDS(&intel_broadwell_gt1_info), ... We'd have: ... INTEL_BDW_GT1_ULT_IDS(&intel_broadwell_gt1_info), INTEL_BDW_GT1_ULX_IDS(&intel_broadwell_gt1_info), INTEL_BDW_GT1_IDS(&intel_broadwell_gt1_info), ... And a separate table to map the id's to subplatform values. Hmm, but we would probably need to extrac the id's from the INTEL_BDW1_GT_IDS like macros so they can be used in this second site without the info parameter. Something like the trick for device info flags, but can it be made to generate a macro? I think not.. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
On 13/11/2018 11:45, Jani Nikula wrote: On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Now that we are down to one caller, which does not even modify copied device info, we can remove the mkwrite_device_info helper and convert the device info pointer itself to be a pointer to static table instead of a copy. Only unfortnate thing is that we need to convert all callsites which were referencing the device info directly to using the INTEL_INFO helper. I'm not sure if that's all that bad. When I was toying around with mkwrite_device_info removal, I actually started off with changing all device info references to INTEL_INFO. It's a big patch, but it nicely centralizes many of the other changes instead of splattering all over the place. Yes, but then you still need to splat all over the place to change the same use sites to RUNTIME_INFO or equivalent. I'd actually like to see RUNTIME_INFO or similar macro as well, just to be able to change the way it's handled later on. I actually started of with introducing INTEL_RUNTIME_INFO but ended up backing off with that idea since it looked to "uppercasey". Not saying that the sprinkle of dev_priv->runtime_info.something is that much better, but at least it did not hurt my eyes so much. Don't know.. I am happy to go with popular vote here. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Remove dead update_wm_pre assignment from SKL wm code
From: Ville Syrjälä SKL+ do not use crtc_state->update_wm_pre, so there is absolutely no point it setting it. crtc_state->update_wm_pre only exists as a temporary hack for pre-g4x platforms until we redo their watermarks to be be atomic. Cc: Stanislav Lisovskiy Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 5d823bdc63a9..9801412062cc 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5473,12 +5473,6 @@ skl_compute_wm(struct drm_atomic_state *state) if (changed) results->dirty_pipes |= drm_crtc_mask(crtc); - - if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0) - /* This pipe's WM's did not change */ - continue; - - intel_cstate->update_wm_pre = true; } skl_print_wm_changes(state); -- 2.18.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Use explicit old crtc state in skl_compute_wm()
From: Ville Syrjälä
skl_compute_wm() wants to compare the old and new watermarks. Currently
it gets at the old watermarks via crtc->state, which is confusing since
it can point at either the old or the new state depending on where
in the sequence we are. In this case it is correct since we have not yet
swapped the states, but let's make it super clear what this is doing
by using the explicit old state.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27498ded4949..6426af873cef 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5435,6 +5435,7 @@ skl_compute_wm(struct drm_atomic_state *state)
{
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
+ struct drm_crtc_state *old_crtc_state;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct skl_ddb_values *results = &intel_state->wm_results;
struct skl_pipe_wm *pipe_wm;
@@ -5462,11 +5463,11 @@ skl_compute_wm(struct drm_atomic_state *state)
* should allow skl_update_pipe_wm() to return failure in cases where
* no suitable watermark values can be found.
*/
- for_each_new_crtc_in_state(state, crtc, cstate, i) {
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, cstate, i) {
struct intel_crtc_state *intel_cstate =
to_intel_crtc_state(cstate);
const struct skl_pipe_wm *old_pipe_wm =
- &to_intel_crtc_state(crtc->state)->wm.skl.optimal;
+ &to_intel_crtc_state(old_crtc_state)->wm.skl.optimal;
pipe_wm = &intel_cstate->wm.skl.optimal;
ret = skl_update_pipe_wm(cstate, old_pipe_wm, pipe_wm,
--
2.18.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Remove bogus FIXME from SKL wm computation
From: Ville Syrjälä
We do return an error when the watermark calculation fails, so
the FIXME claiming otherwise is outdated. Remove it.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6426af873cef..5d823bdc63a9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5458,10 +5458,6 @@ skl_compute_wm(struct drm_atomic_state *state)
* Note that the DDB allocation above may have added more CRTC's that
* weren't otherwise being modified (and set bits in dirty_pipes) if
* pipe allocations had to change.
-*
-* FIXME: Now that we're doing this in the atomic check phase, we
-* should allow skl_update_pipe_wm() to return failure in cases where
-* no suitable watermark values can be found.
*/
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, cstate, i) {
struct intel_crtc_state *intel_cstate =
--
2.18.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
On 13/11/2018 11:51, Chris Wilson wrote: Quoting Jani Nikula (2018-11-13 11:45:02) On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Now that we are down to one caller, which does not even modify copied device info, we can remove the mkwrite_device_info helper and convert the device info pointer itself to be a pointer to static table instead of a copy. Only unfortnate thing is that we need to convert all callsites which were referencing the device info directly to using the INTEL_INFO helper. I'm not sure if that's all that bad. When I was toying around with mkwrite_device_info removal, I actually started off with changing all device info references to INTEL_INFO. It's a big patch, but it nicely centralizes many of the other changes instead of splattering all over the place. Fwiw, replacing all the static i915->info accesses with INTEL_INFO (or DEVICE_INFO since STATIC_INFO I think is too confusing with C, and INTEL_INFO is not distinct enough from RUNTIME_INFO) is perhaps a You propose DEVICE_INFO for the static part and RUNTIME_INFO for dynamic, all with INTEL_ prefix? pre-requisite for single platform DCE. Along the lines of #define INTEL_INFO(i915) (&skylake_gt3_info) Definitely, and I think this patch changed them all. There weren't that many. We also need to minimize the runtime portion for best DCE results. But AFAIR it was quite good already with just IS_GEN and IS_PLATFORM changes and not even LTO. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Remove mkwrite_device_info
Quoting Tvrtko Ursulin (2018-11-13 17:33:38) > > On 13/11/2018 11:51, Chris Wilson wrote: > > Quoting Jani Nikula (2018-11-13 11:45:02) > >> On Mon, 12 Nov 2018, Tvrtko Ursulin wrote: > >>> From: Tvrtko Ursulin > >>> > >>> Now that we are down to one caller, which does not even modify copied > >>> device info, we can remove the mkwrite_device_info helper and convert the > >>> device info pointer itself to be a pointer to static table instead of a > >>> copy. > >>> > >>> Only unfortnate thing is that we need to convert all callsites which were > >>> referencing the device info directly to using the INTEL_INFO helper. > >> > >> I'm not sure if that's all that bad. When I was toying around with > >> mkwrite_device_info removal, I actually started off with changing all > >> device info references to INTEL_INFO. It's a big patch, but it nicely > >> centralizes many of the other changes instead of splattering all over > >> the place. > > > > Fwiw, replacing all the static i915->info accesses with INTEL_INFO (or > > DEVICE_INFO since STATIC_INFO I think is too confusing with C, and > > INTEL_INFO is not distinct enough from RUNTIME_INFO) is perhaps a > > You propose DEVICE_INFO for the static part and RUNTIME_INFO for > dynamic, all with INTEL_ prefix? INTEL_DEVICE_INFO() INTEL_RUNTIME_INFO() is getting unwieldy? I just used DEVICE_INFO() and RUNTIME_INFO(). Although, there aren't that many direct users of INTEL_*_INFO() so I guess it's not that bad, and any that are, merit a shorter helper. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/icl: reverse uninit order
On Tue, Nov 13, 2018 at 03:23:07PM +0200, Imre Deak wrote:
> On Tue, Nov 13, 2018 at 03:19:06PM +0200, Imre Deak wrote:
> > On Mon, Nov 12, 2018 at 06:45:03PM -0800, Lucas De Marchi wrote:
> > > Bspec 21257 says "DDIA PHY is the comp master, so it must
> > > not be un-initialized if other combo PHYs are in use". Here
> > > we are shutting down all phys, so it's not strictly required.
> > > However let's be consistent on deinitializing things in the
> > > reversed order we initialized them.
> > >
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/intel_combo_phy.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
> > > b/drivers/gpu/drm/i915/intel_combo_phy.c
> > > index 49f3a533860d..9c06be45b84e 100644
> > > --- a/drivers/gpu/drm/i915/intel_combo_phy.c
> > > +++ b/drivers/gpu/drm/i915/intel_combo_phy.c
> > > @@ -9,6 +9,12 @@
> > > for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
> > > for_each_if(intel_port_is_combophy(__dev_priv, __port))
> > >
> > > +#define for_each_combo_port_rev(__dev_priv, __port) \
> > > + for ((__port) = I915_MAX_PORTS - 1; \
> > > + (__port) >= PORT_A && (__port) < I915_MAX_PORTS; \
> > > + (__port)--) \
> >
> > Heh, so 'enum port' is unsigned. Surely I would have get this right
> > only after seeing it fail with only the >= condition :) An
> > alternative:
> >
> > for ((__port) = I915_MAX_PORTS; (__port)-- > 0;)
> >
> > or add a negative value, like INVALID_PORT=-1 to 'enum port', but we'd
>
> Hm, actually we do have PORT_NONE=-1, in which case 'enum port' is a
> signed int. So why do we need (__port) < I915_MAX_PORTS ?
We don't actually *need*. I only thought the fact that the type is not explicit
but rather depends on the enum value, it would be to fragile and it would start
to fail silently if we ever change that. I like the alternative you gave since
it's
shorter and works on both cases.
thanks
Lucas De Marchi
>
> > need some user for that too. Either way:
> >
> > Reviewed-by: Imre Deak
> >
> > > + for_each_if(intel_port_is_combophy(__dev_priv, __port))
> > > +
> > > enum {
> > > PROCMON_0_85V_DOT_0,
> > > PROCMON_0_95V_DOT_0,
> > > @@ -232,7 +238,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
> > > *dev_priv)
> > > {
> > > enum port port;
> > >
> > > - for_each_combo_port(dev_priv, port) {
> > > + for_each_combo_port_rev(dev_priv, port) {
> > > u32 val;
> > >
> > > if (!icl_combo_phy_verify_state(dev_priv, port))
> > > --
> > > 2.19.1.1.g56c4683e68
> > >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Disable LP3 watermarks on all SNB machines
From: Ville Syrjälä
I have a Thinkpad X220 Tablet in my hands that is losing vblank
interrupts whenever LP3 watermarks are used.
If I nudge the latency value written to the WM3 register just
by one in either direction the problem disappears. That to me
suggests that the punit will not enter the corrsponding
powersave mode (MPLL shutdown IIRC) unless the latency value
in the register matches exactly what we read from SSKPD. Ie.
it's not really a latency value but rather just a cookie
by which the punit can identify the desired power saving state.
On HSW/BDW this was changed such that we actually just write
the WM level number into those bits, which makes much more
sense given the observed behaviour.
We could try to handle this by disallowing LP3 watermarks
only when vblank interrupts are enabled but we'd first have
to prove that only vblank interrupts are affected, which
seems unlikely. Also we can't grab the wm mutex from the
vblank enable/disable hooks because those are called with
various spinlocks held. Thus we'd have to redesigne the
watermark locking. So to play it safe and keep the code
simple we simply disable LP3 watermarks on all SNB machines.
To do that we simply zero out the latency values for
watermark level 3, and we adjust the watermark computation
to check for that. The behaviour now matches that of the
g4x/vlv/skl wm code in the presence of a zeroed latency
value.
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27498ded4949..ef1ae2ede379 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2493,6 +2493,9 @@ static uint32_t ilk_compute_pri_wm(const struct
intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
+ if (mem_value == 0)
+ return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2522,6 +2525,9 @@ static uint32_t ilk_compute_spr_wm(const struct
intel_crtc_state *cstate,
uint32_t method1, method2;
int cpp;
+ if (mem_value == 0)
+ return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -2545,6 +2551,9 @@ static uint32_t ilk_compute_cur_wm(const struct
intel_crtc_state *cstate,
{
int cpp;
+ if (mem_value == 0)
+ return USHRT_MAX;
+
if (!intel_wm_plane_visible(cstate, pstate))
return 0;
@@ -3008,6 +3017,34 @@ static void snb_wm_latency_quirk(struct drm_i915_private
*dev_priv)
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
}
+static void snb_wm_lp3_irq_quirk(struct drm_i915_private *dev_priv)
+{
+ /*
+* On some SNB machines (Thinkpad X220 Tablet at least)
+* LP3 usage can cause vblank interrupts to be lost.
+* The DEIIR bit will go high but it looks like the CPU
+* never gets interrupted.
+*
+* It's not clear whether other interrupt source could
+* be affected or if this is somehow limited to vblank
+* interrupts only. To play it safe we disable LP3
+* watermarks entirely.
+*/
+ if (dev_priv->wm.pri_latency[3] == 0 &&
+ dev_priv->wm.spr_latency[3] == 0 &&
+ dev_priv->wm.cur_latency[3] == 0)
+ return;
+
+ dev_priv->wm.pri_latency[3] = 0;
+ dev_priv->wm.spr_latency[3] = 0;
+ dev_priv->wm.cur_latency[3] = 0;
+
+ DRM_DEBUG_KMS("LP3 watermarks disabled due to potential for lost
interrupts\n");
+ intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
+ intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
+ intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
+}
+
static void ilk_setup_wm_latency(struct drm_i915_private *dev_priv)
{
intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency);
@@ -3024,8 +3061,10 @@ static void ilk_setup_wm_latency(struct drm_i915_private
*dev_priv)
intel_print_wm_latency(dev_priv, "Sprite", dev_priv->wm.spr_latency);
intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
- if (IS_GEN6(dev_priv))
+ if (IS_GEN6(dev_priv)) {
snb_wm_latency_quirk(dev_priv);
+ snb_wm_lp3_irq_quirk(dev_priv);
+ }
}
static void skl_setup_wm_latency(struct drm_i915_private *dev_priv)
--
2.18.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Use explicit old crtc state in skl_compute_wm()
== Series Details == Series: series starting with [1/3] drm/i915: Use explicit old crtc state in skl_compute_wm() URL : https://patchwork.freedesktop.org/series/52436/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5133 -> Patchwork_10816 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/52436/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10816 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_busy@basic-flip-b: fi-hsw-peppy: PASS -> FAIL (fdo#103182) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) Possible fixes igt@drv_selftest@live_hangcheck: fi-bwr-2160:DMESG-FAIL (fdo#108735) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103182 https://bugs.freedesktop.org/show_bug.cgi?id=103182 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108735 https://bugs.freedesktop.org/show_bug.cgi?id=108735 == Participating hosts (53 -> 45) == Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_5133 -> Patchwork_10816 CI_DRM_5133: 5c71926a1834348a68951622a950de0355b73450 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10816: 5aa5c7a34c312bb224f5f22c140ff5d113fb089e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5aa5c7a34c31 drm/i915: Remove dead update_wm_pre assignment from SKL wm code 57ff2d377da8 drm/i915: Remove bogus FIXME from SKL wm computation 5c01f5293e5b drm/i915: Use explicit old crtc state in skl_compute_wm() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10816/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable LP3 watermarks on all SNB machines
Quoting Ville Syrjala (2018-11-13 18:10:23)
> From: Ville Syrjälä
>
> I have a Thinkpad X220 Tablet in my hands that is losing vblank
> interrupts whenever LP3 watermarks are used.
>
> If I nudge the latency value written to the WM3 register just
> by one in either direction the problem disappears. That to me
> suggests that the punit will not enter the corrsponding
> powersave mode (MPLL shutdown IIRC) unless the latency value
> in the register matches exactly what we read from SSKPD. Ie.
> it's not really a latency value but rather just a cookie
> by which the punit can identify the desired power saving state.
> On HSW/BDW this was changed such that we actually just write
> the WM level number into those bits, which makes much more
> sense given the observed behaviour.
>
> We could try to handle this by disallowing LP3 watermarks
> only when vblank interrupts are enabled but we'd first have
> to prove that only vblank interrupts are affected, which
> seems unlikely. Also we can't grab the wm mutex from the
> vblank enable/disable hooks because those are called with
> various spinlocks held. Thus we'd have to redesigne the
> watermark locking. So to play it safe and keep the code
> simple we simply disable LP3 watermarks on all SNB machines.
>
> To do that we simply zero out the latency values for
> watermark level 3, and we adjust the watermark computation
> to check for that. The behaviour now matches that of the
> g4x/vlv/skl wm code in the presence of a zeroed latency
> value.
>
> Cc: sta...@vger.kernel.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 41 -
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 27498ded4949..ef1ae2ede379 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2493,6 +2493,9 @@ static uint32_t ilk_compute_pri_wm(const struct
> intel_crtc_state *cstate,
> uint32_t method1, method2;
> int cpp;
>
> + if (mem_value == 0)
> + return USHRT_MAX;
> +
> if (!intel_wm_plane_visible(cstate, pstate))
> return 0;
>
> @@ -2522,6 +2525,9 @@ static uint32_t ilk_compute_spr_wm(const struct
> intel_crtc_state *cstate,
> uint32_t method1, method2;
> int cpp;
>
> + if (mem_value == 0)
> + return USHRT_MAX;
> +
> if (!intel_wm_plane_visible(cstate, pstate))
> return 0;
>
> @@ -2545,6 +2551,9 @@ static uint32_t ilk_compute_cur_wm(const struct
> intel_crtc_state *cstate,
> {
> int cpp;
>
> + if (mem_value == 0)
> + return USHRT_MAX;
> +
> if (!intel_wm_plane_visible(cstate, pstate))
> return 0;
>
> @@ -3008,6 +3017,34 @@ static void snb_wm_latency_quirk(struct
> drm_i915_private *dev_priv)
> intel_print_wm_latency(dev_priv, "Cursor", dev_priv->wm.cur_latency);
> }
>
> +static void snb_wm_lp3_irq_quirk(struct drm_i915_private *dev_priv)
> +{
> + /*
> +* On some SNB machines (Thinkpad X220 Tablet at least)
> +* LP3 usage can cause vblank interrupts to be lost.
> +* The DEIIR bit will go high but it looks like the CPU
> +* never gets interrupted.
> +*
> +* It's not clear whether other interrupt source could
> +* be affected or if this is somehow limited to vblank
> +* interrupts only. To play it safe we disable LP3
> +* watermarks entirely.
> +*/
> + if (dev_priv->wm.pri_latency[3] == 0 &&
> + dev_priv->wm.spr_latency[3] == 0 &&
> + dev_priv->wm.cur_latency[3] == 0)
> + return;
> +
> + dev_priv->wm.pri_latency[3] = 0;
> + dev_priv->wm.spr_latency[3] = 0;
> + dev_priv->wm.cur_latency[3] = 0;
-> return USHRT_MAX for pri/spr/cur planes.
-> result->enable = false;
Only question then why USHRT_MAX for a u32 parameter? Seems to be copied
from gm45 where it is a u16 parameter instead.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable LP3 watermarks on all SNB machines
On Tue, Nov 13, 2018 at 06:25:47PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-11-13 18:10:23)
> > From: Ville Syrjälä
> >
> > I have a Thinkpad X220 Tablet in my hands that is losing vblank
> > interrupts whenever LP3 watermarks are used.
> >
> > If I nudge the latency value written to the WM3 register just
> > by one in either direction the problem disappears. That to me
> > suggests that the punit will not enter the corrsponding
> > powersave mode (MPLL shutdown IIRC) unless the latency value
> > in the register matches exactly what we read from SSKPD. Ie.
> > it's not really a latency value but rather just a cookie
> > by which the punit can identify the desired power saving state.
> > On HSW/BDW this was changed such that we actually just write
> > the WM level number into those bits, which makes much more
> > sense given the observed behaviour.
> >
> > We could try to handle this by disallowing LP3 watermarks
> > only when vblank interrupts are enabled but we'd first have
> > to prove that only vblank interrupts are affected, which
> > seems unlikely. Also we can't grab the wm mutex from the
> > vblank enable/disable hooks because those are called with
> > various spinlocks held. Thus we'd have to redesigne the
> > watermark locking. So to play it safe and keep the code
> > simple we simply disable LP3 watermarks on all SNB machines.
> >
> > To do that we simply zero out the latency values for
> > watermark level 3, and we adjust the watermark computation
> > to check for that. The behaviour now matches that of the
> > g4x/vlv/skl wm code in the presence of a zeroed latency
> > value.
> >
> > Cc: sta...@vger.kernel.org
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 41 -
> > 1 file changed, 40 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 27498ded4949..ef1ae2ede379 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2493,6 +2493,9 @@ static uint32_t ilk_compute_pri_wm(const struct
> > intel_crtc_state *cstate,
> > uint32_t method1, method2;
> > int cpp;
> >
> > + if (mem_value == 0)
> > + return USHRT_MAX;
> > +
> > if (!intel_wm_plane_visible(cstate, pstate))
> > return 0;
> >
> > @@ -2522,6 +2525,9 @@ static uint32_t ilk_compute_spr_wm(const struct
> > intel_crtc_state *cstate,
> > uint32_t method1, method2;
> > int cpp;
> >
> > + if (mem_value == 0)
> > + return USHRT_MAX;
> > +
> > if (!intel_wm_plane_visible(cstate, pstate))
> > return 0;
> >
> > @@ -2545,6 +2551,9 @@ static uint32_t ilk_compute_cur_wm(const struct
> > intel_crtc_state *cstate,
> > {
> > int cpp;
> >
> > + if (mem_value == 0)
> > + return USHRT_MAX;
> > +
> > if (!intel_wm_plane_visible(cstate, pstate))
> > return 0;
> >
> > @@ -3008,6 +3017,34 @@ static void snb_wm_latency_quirk(struct
> > drm_i915_private *dev_priv)
> > intel_print_wm_latency(dev_priv, "Cursor",
> > dev_priv->wm.cur_latency);
> > }
> >
> > +static void snb_wm_lp3_irq_quirk(struct drm_i915_private *dev_priv)
> > +{
> > + /*
> > +* On some SNB machines (Thinkpad X220 Tablet at least)
> > +* LP3 usage can cause vblank interrupts to be lost.
> > +* The DEIIR bit will go high but it looks like the CPU
> > +* never gets interrupted.
> > +*
> > +* It's not clear whether other interrupt source could
> > +* be affected or if this is somehow limited to vblank
> > +* interrupts only. To play it safe we disable LP3
> > +* watermarks entirely.
> > +*/
> > + if (dev_priv->wm.pri_latency[3] == 0 &&
> > + dev_priv->wm.spr_latency[3] == 0 &&
> > + dev_priv->wm.cur_latency[3] == 0)
> > + return;
> > +
> > + dev_priv->wm.pri_latency[3] = 0;
> > + dev_priv->wm.spr_latency[3] = 0;
> > + dev_priv->wm.cur_latency[3] = 0;
>
> -> return USHRT_MAX for pri/spr/cur planes.
> -> result->enable = false;
>
> Only question then why USHRT_MAX for a u32 parameter? Seems to be copied
> from gm45 where it is a u16 parameter instead.
A good question. My excuse is that I was expecting it to be a u16.
The max value the registers can hold is 11 bits, so u16 would be
more than enough for our needs.
Looks like we store these as u32 in the struct as well so we end
up wasting a bit of memory. I'll go write a patch to shrink it
a bit.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable LP3 watermarks on all SNB machines
== Series Details == Series: drm/i915: Disable LP3 watermarks on all SNB machines URL : https://patchwork.freedesktop.org/series/52440/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5133 -> Patchwork_10817 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/52440/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10817 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-icl-u2: PASS -> DMESG-WARN (fdo#107724) igt@gem_exec_suspend@basic-s4-devices: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_frontbuffer_tracking@basic: fi-icl-u2: PASS -> FAIL (fdo#103167) Possible fixes igt@drv_selftest@live_hangcheck: fi-bwr-2160:DMESG-FAIL (fdo#108735) -> PASS igt@gem_ctx_switch@basic-default: fi-icl-u2: DMESG-WARN (fdo#107724) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724 fdo#108735 https://bugs.freedesktop.org/show_bug.cgi?id=108735 == Participating hosts (53 -> 47) == Missing(6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_5133 -> Patchwork_10817 CI_DRM_5133: 5c71926a1834348a68951622a950de0355b73450 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10817: 1192a5586c45b581271fffcf310ba2904b108f31 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1192a5586c45 drm/i915: Disable LP3 watermarks on all SNB machines == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10817/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel v8 2/2] sna: Added AYUV format support for textured and sprite video adapters.
Quoting Stanislav Lisovskiy (2018-11-13 07:45:02)
> @@ -408,6 +424,9 @@ void sna_video_textured_setup(struct sna *sna, ScreenPtr
> screen)
> } else if (sna->kgem.gen < 040) {
> adaptor->nImages = ARRAY_SIZE(gen3_Images);
> adaptor->pImages = (XvImageRec *)gen3_Images;
> + } else if (sna->kgem.gen >= 0110) {
> + adaptor->nImages = ARRAY_SIZE(gen9_Images);
> + adaptor->pImages = (XvImageRec *)gen9_Images;
> } else {
> adaptor->nImages = ARRAY_SIZE(gen4_Images);
> adaptor->pImages = (XvImageRec *)gen4_Images;
Grr. Aside from the minor nits, ok. Ville?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Fix the possible watermark miswriting
== Series Details == Series: Fix the possible watermark miswriting URL : https://patchwork.freedesktop.org/series/52423/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5132_full -> Patchwork_10813_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10813_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10813_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10813_full: === IGT changes === Warnings igt@perf_pmu@rc6: shard-kbl: PASS -> SKIP igt@tools_test@tools_test: shard-apl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10813_full that come from known issues: === IGT changes === Issues hit igt@kms_ccs@pipe-b-crc-sprite-planes-basic: shard-glk: PASS -> FAIL (fdo#108145) igt@kms_color@pipe-c-legacy-gamma: shard-apl: PASS -> FAIL (fdo#104782) igt@kms_cursor_crc@cursor-128x128-random: shard-apl: PASS -> FAIL (fdo#103232) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: shard-glk: PASS -> FAIL (fdo#103167) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: shard-apl: PASS -> FAIL (fdo#103167) +2 igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: shard-skl: PASS -> FAIL (fdo#107815) igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max: shard-glk: NOTRUN -> FAIL (fdo#108145) igt@kms_plane_multiple@atomic-pipe-c-tiling-y: shard-glk: PASS -> FAIL (fdo#103166) igt@kms_vblank@pipe-b-ts-continuation-suspend: shard-skl: PASS -> INCOMPLETE (fdo#104108, fdo#107773) igt@perf@polling: shard-hsw: PASS -> FAIL (fdo#102252) igt@perf_pmu@busy-start-vcs0: shard-apl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +1 igt@pm_rpm@pc8-residency: shard-skl: SKIP -> INCOMPLETE (fdo#107807) +1 igt@pm_rpm@universal-planes-dpms: shard-skl: PASS -> INCOMPLETE (fdo#107807) Possible fixes igt@drv_suspend@shrink: shard-skl: INCOMPLETE (fdo#106886) -> PASS igt@gem_exec_suspend@basic-s3: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS igt@gem_exec_whisper@normal: shard-skl: TIMEOUT (fdo#108592) -> PASS igt@gem_tiled_blits@normal: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@kms_color@pipe-a-ctm-0-75: shard-skl: FAIL (fdo#108682) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-pwrite: shard-apl: FAIL (fdo#103167) -> PASS +1 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff: shard-glk: FAIL (fdo#103167) -> PASS +2 igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: shard-skl: INCOMPLETE (fdo#104108, fdo#107773) -> PASS igt@kms_plane_multiple@atomic-pipe-b-tiling-y: shard-apl: FAIL (fdo#103166) -> PASS igt@kms_properties@plane-properties-atomic: shard-kbl: DMESG-WARN (fdo#103313, fdo#105345) -> PASS igt@kms_setmode@basic: shard-hsw: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#104782 https://bugs.freedesktop.org/show_bug.cgi?id=104782 fdo#105345 https://bugs.freedesktop.org/show_bug.cgi?id=105345 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807 fdo#107815 https://bugs.freedesktop.org/show_bug.cgi?id=107815 fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145 fdo#108592 https://bugs.freedesktop.org/show_bug.cgi?id=108592 fdo#108682 https://bugs.freedesktop.org/show_bug.cgi?id=108682 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=19813
[Intel-gfx] [PATCH v2] drm/i915/icl: reverse uninit order
Bspec 21257 says "DDIA PHY is the comp master, so it must
not be un-initialized if other combo PHYs are in use". Here
we are shutting down all phys, so it's not strictly required.
However let's be consistent on deinitializing things in the
reversed order we initialized them.
v2: simplify protection for enum port being unsigned in future
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_combo_phy.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
b/drivers/gpu/drm/i915/intel_combo_phy.c
index 49f3a533860d..62939df048d7 100644
--- a/drivers/gpu/drm/i915/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/intel_combo_phy.c
@@ -9,6 +9,10 @@
for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
for_each_if(intel_port_is_combophy(__dev_priv, __port))
+#define for_each_combo_port_rev(__dev_priv, __port) \
+ for ((__port) = I915_MAX_PORTS; (__port)-- > PORT_A;) \
+ for_each_if(intel_port_is_combophy(__dev_priv, __port))
+
enum {
PROCMON_0_85V_DOT_0,
PROCMON_0_95V_DOT_0,
@@ -232,7 +236,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
*dev_priv)
{
enum port port;
- for_each_combo_port(dev_priv, port) {
+ for_each_combo_port_rev(dev_priv, port) {
u32 val;
if (!icl_combo_phy_verify_state(dev_priv, port))
--
2.19.1.1.g56c4683e68
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915/icl: replace check for combo phy (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915/icl: replace check for combo phy (rev2) URL : https://patchwork.freedesktop.org/series/52400/ State : warning == Summary == $ dim checkpatch origin/drm-tip cf571a614561 drm/i915/icl: replace check for combo phy -:23: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__port' - possible side-effects? #23: FILE: drivers/gpu/drm/i915/intel_combo_phy.c:8: +#define for_each_combo_port(__dev_priv, __port) \ + for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \ + for_each_if(intel_port_is_combophy(__dev_priv, __port)) total: 0 errors, 0 warnings, 1 checks, 26 lines checked bf6d9fe15951 drm/i915/icl: reverse uninit order -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__port' - possible side-effects? #24: FILE: drivers/gpu/drm/i915/intel_combo_phy.c:12: +#define for_each_combo_port_rev(__dev_priv, __port) \ + for ((__port) = I915_MAX_PORTS; (__port)-- > PORT_A;) \ + for_each_if(intel_port_is_combophy(__dev_priv, __port)) total: 0 errors, 0 warnings, 1 checks, 18 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel v8 2/2] sna: Added AYUV format support for textured and sprite video adapters.
On Tue, Nov 13, 2018 at 06:49:38PM +, Chris Wilson wrote:
> Quoting Stanislav Lisovskiy (2018-11-13 07:45:02)
> > @@ -408,6 +424,9 @@ void sna_video_textured_setup(struct sna *sna,
> > ScreenPtr screen)
> > } else if (sna->kgem.gen < 040) {
> > adaptor->nImages = ARRAY_SIZE(gen3_Images);
> > adaptor->pImages = (XvImageRec *)gen3_Images;
> > + } else if (sna->kgem.gen >= 0110) {
> > + adaptor->nImages = ARRAY_SIZE(gen9_Images);
> > + adaptor->pImages = (XvImageRec *)gen9_Images;
> > } else {
> > adaptor->nImages = ARRAY_SIZE(gen4_Images);
> > adaptor->pImages = (XvImageRec *)gen4_Images;
>
> Grr. Aside from the minor nits, ok. Ville?
Yeah. Seems good enough. For both
Reviewed-by: Ville Syrjälä
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/icl: replace check for combo phy (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915/icl: replace check for combo phy (rev2) URL : https://patchwork.freedesktop.org/series/52400/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5133 -> Patchwork_10818 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/52400/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_10818 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-bsw-kefka: PASS -> FAIL (fdo#108656) igt@kms_chamelium@common-hpd-after-suspend: fi-skl-6700k2: PASS -> WARN (fdo#108680) igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: fi-ilk-650: PASS -> DMESG-WARN (fdo#106387) Possible fixes igt@drv_selftest@live_hangcheck: fi-bwr-2160:DMESG-FAIL (fdo#108735) -> PASS igt@gem_ctx_switch@basic-default: fi-icl-u2: DMESG-WARN (fdo#107724) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: DMESG-WARN (fdo#102614) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#106387 https://bugs.freedesktop.org/show_bug.cgi?id=106387 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724 fdo#108656 https://bugs.freedesktop.org/show_bug.cgi?id=108656 fdo#108680 https://bugs.freedesktop.org/show_bug.cgi?id=108680 fdo#108735 https://bugs.freedesktop.org/show_bug.cgi?id=108735 == Participating hosts (53 -> 46) == Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_5133 -> Patchwork_10818 CI_DRM_5133: 5c71926a1834348a68951622a950de0355b73450 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4714: cab148ca3ec904a94d0cd43476cf7e1f8663f906 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10818: bf6d9fe159515700d2b86b87fa10304924af75aa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == bf6d9fe15951 drm/i915/icl: reverse uninit order cf571a614561 drm/i915/icl: replace check for combo phy == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10818/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Fix the possible watermark miswriting for skl+
== Series Details == Series: Fix the possible watermark miswriting for skl+ URL : https://patchwork.freedesktop.org/series/52425/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5132_full -> Patchwork_10814_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10814_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10814_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10814_full: === IGT changes === Warnings igt@kms_atomic_interruptible@universal-setplane-cursor: shard-snb: PASS -> SKIP +2 igt@perf_pmu@rc6: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10814_full that come from known issues: === IGT changes === Issues hit igt@gem_softpin@noreloc-s3: shard-skl: PASS -> INCOMPLETE (fdo#104108, fdo#107773) igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c: shard-kbl: NOTRUN -> DMESG-WARN (fdo#107956) igt@kms_ccs@pipe-b-crc-sprite-planes-basic: shard-kbl: NOTRUN -> DMESG-WARN (fdo#103313) igt@kms_color@pipe-c-legacy-gamma: shard-apl: PASS -> FAIL (fdo#104782) igt@kms_cursor_crc@cursor-128x128-random: shard-apl: PASS -> FAIL (fdo#103232) igt@kms_flip@plain-flip-ts-check: shard-skl: PASS -> FAIL (fdo#100368) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff: shard-apl: PASS -> FAIL (fdo#103167) +1 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-gtt: shard-glk: PASS -> FAIL (fdo#103167) igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max: shard-glk: NOTRUN -> FAIL (fdo#108145) igt@kms_plane_lowres@pipe-b-tiling-none: shard-kbl: NOTRUN -> DMESG-WARN (fdo#105345) igt@kms_properties@connector-properties-legacy: shard-kbl: PASS -> DMESG-WARN (fdo#105345, fdo#103313) igt@pm_rpm@gem-pread: shard-skl: PASS -> INCOMPLETE (fdo#107807) igt@pm_rpm@modeset-pc8-residency-stress: shard-skl: SKIP -> INCOMPLETE (fdo#107807) Possible fixes igt@drm_import_export@import-close-race-flink: shard-skl: TIMEOUT (fdo#108667) -> PASS igt@gem_exec_suspend@basic-s3: shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> PASS igt@gem_exec_whisper@normal: shard-skl: TIMEOUT (fdo#108592) -> PASS igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665, fdo#106887) -> PASS igt@gem_tiled_blits@normal: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-skl: DMESG-WARN (fdo#107956) -> PASS igt@kms_cursor_crc@cursor-256x256-onscreen: shard-skl: FAIL (fdo#103232) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: shard-glk: FAIL (fdo#103167) -> PASS +1 igt@kms_plane@plane-position-covered-pipe-b-planes: shard-glk: FAIL (fdo#103166) -> PASS igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: shard-skl: FAIL (fdo#107815) -> PASS igt@kms_plane_multiple@atomic-pipe-b-tiling-y: shard-apl: FAIL (fdo#103166) -> PASS igt@kms_properties@plane-properties-atomic: shard-kbl: DMESG-WARN (fdo#105345, fdo#103313) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#104782 https://bugs.freedesktop.org/show_bug.cgi?id=104782 fdo#105345 https://bugs.freedesktop.org/show_bug.cgi?id=105345 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106887 https://bugs.freedesktop.org/show_bug.cgi?id=106887 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=1
Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add and export function to parse manufacturer id
On Thu, 08 Nov 2018, Daniel Vetter wrote:
> On Thu, Nov 08, 2018 at 08:42:52PM +, Souza, Jose wrote:
>> On Thu, 2018-11-08 at 09:31 +0100, Daniel Vetter wrote:
>> > On Wed, Nov 07, 2018 at 04:23:52PM -0800, José Roberto de Souza
>> > wrote:
>> > > This function will be helpful to drivers that wants to add its own
>> > > quirks to sinks.
>> >
>> > Why would you want to do that? The point of a shared edid parsing
>> > code is
>> > that we can share all these quirks ...
>> >
>> > For these kind of patches, always include the driver code that makes
>> > use
>> > of your new code too. That makes it much easier to answer these
>> > questions.
>>
>> This will be used to disable or enable with quirks PSR in some panels
>> that do not behave like eDP spec states.
>> As this would be specifc to i915, I guess is better keep the list only
>> in i915.
>>
>> What is your opinion about that?
>
> For anything dp, shouldn't we use the OUI instead? Or is that more garbage
> than the EDID serial?
The OUI isn't always present, but we can use it when it is. And we
already have DPCD quirk support for that in drm_dp_helper.c.
> And yes, psr quirking for i915 seems like a reasonable thing to do, using
> either approach. But definitely include the full picture, including i915
> patches, in your next round.
I think all of the quirk matching should be in drm core or helpers. For
most quirks, it's up to the drivers to actually do something with that
information anyway, so it'll still remain i915 specific.
BR,
Jani.
> -Daniel
>
>>
>> >
>> > Thanks, Daniel
>> >
>> >
>> > > Signed-off-by: José Roberto de Souza
>> > > ---
>> > > drivers/gpu/drm/drm_edid.c | 20
>> > > include/drm/drm_edid.h | 1 +
>> > > 2 files changed, 17 insertions(+), 4 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_edid.c
>> > > b/drivers/gpu/drm/drm_edid.c
>> > > index b506e3622b08..1a0ddf3d326b 100644
>> > > --- a/drivers/gpu/drm/drm_edid.c
>> > > +++ b/drivers/gpu/drm/drm_edid.c
>> > > @@ -1755,6 +1755,21 @@ EXPORT_SYMBOL(drm_edid_duplicate);
>> > >
>> > > /*** EDID parsing ***/
>> > >
>> > > +/**
>> > > + * drm_edid_manufacturer_parse - parse the EDID manufacturer id to
>> > > readable
>> > > + * characters and set into manufacturer parameter.
>> > > + * @edid: EDID to get the manufacturer
>> > > + * @manufacturer: the char buffer to store the id
>> > > + */
>> > > +void drm_edid_manufacturer_parse(const struct edid *edid, char
>> > > manufacturer[3])
>> > > +{
>> > > +manufacturer[0] = ((edid->mfg_id[0] & 0x7c) >> 2) + '@';
>> > > +manufacturer[1] = (((edid->mfg_id[0] & 0x3) << 3) |
>> > > + ((edid->mfg_id[1] & 0xe0) >> 5)) + '@';
>> > > +manufacturer[2] = (edid->mfg_id[1] & 0x1f) + '@';
>> > > +}
>> > > +EXPORT_SYMBOL(drm_edid_manufacturer_parse);
>> > > +
>> > > /**
>> > > * edid_vendor - match a string against EDID's obfuscated vendor
>> > > field
>> > > * @edid: EDID to match
>> > > @@ -1766,10 +1781,7 @@ static bool edid_vendor(const struct edid
>> > > *edid, const char *vendor)
>> > > {
>> > > char edid_vendor[3];
>> > >
>> > > -edid_vendor[0] = ((edid->mfg_id[0] & 0x7c) >> 2) + '@';
>> > > -edid_vendor[1] = (((edid->mfg_id[0] & 0x3) << 3) |
>> > > - ((edid->mfg_id[1] & 0xe0) >> 5)) + '@';
>> > > -edid_vendor[2] = (edid->mfg_id[1] & 0x1f) + '@';
>> > > +drm_edid_manufacturer_parse(edid, edid_vendor);
>> > >
>> > > return !strncmp(edid_vendor, vendor, 3);
>> > > }
>> > > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>> > > index e3c404833115..e4f3f7f34d6a 100644
>> > > --- a/include/drm/drm_edid.h
>> > > +++ b/include/drm/drm_edid.h
>> > > @@ -466,6 +466,7 @@ struct edid *drm_get_edid_switcheroo(struct
>> > > drm_connector *connector,
>> > > struct i2c_adapter *adapter);
>> > > struct edid *drm_edid_duplicate(const struct edid *edid);
>> > > int drm_add_edid_modes(struct drm_connector *connector, struct
>> > > edid *edid);
>> > > +void drm_edid_manufacturer_parse(const struct edid *edid, char
>> > > manufacturer[3]);
>> > >
>> > > u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
>> > > enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8
>> > > video_code);
>> > > --
>> > > 2.19.1
>> > >
>> > > ___
>> > > Intel-gfx mailing list
>> > > Intel-gfx@lists.freedesktop.org
>> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: reverse uninit order
On Tue, 13 Nov 2018, Lucas De Marchi wrote:
> Bspec 21257 says "DDIA PHY is the comp master, so it must
> not be un-initialized if other combo PHYs are in use". Here
> we are shutting down all phys, so it's not strictly required.
> However let's be consistent on deinitializing things in the
> reversed order we initialized them.
>
> v2: simplify protection for enum port being unsigned in future
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_combo_phy.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
> b/drivers/gpu/drm/i915/intel_combo_phy.c
> index 49f3a533860d..62939df048d7 100644
> --- a/drivers/gpu/drm/i915/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/intel_combo_phy.c
> @@ -9,6 +9,10 @@
> for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
> for_each_if(intel_port_is_combophy(__dev_priv, __port))
>
> +#define for_each_combo_port_rev(__dev_priv, __port) \
The list.h list macros use _reverse suffix for reverse traversal. I
think we can afford to spend the extra letters here too.
BR,
Jani.
> + for ((__port) = I915_MAX_PORTS; (__port)-- > PORT_A;) \
> + for_each_if(intel_port_is_combophy(__dev_priv, __port))
> +
> enum {
> PROCMON_0_85V_DOT_0,
> PROCMON_0_95V_DOT_0,
> @@ -232,7 +236,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
> *dev_priv)
> {
> enum port port;
>
> - for_each_combo_port(dev_priv, port) {
> + for_each_combo_port_rev(dev_priv, port) {
> u32 val;
>
> if (!icl_combo_phy_verify_state(dev_priv, port))
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH xf86-video-intel v8 2/2] sna: Added AYUV format support for textured and sprite video adapters.
Quoting Ville Syrjälä (2018-11-13 19:13:40)
> On Tue, Nov 13, 2018 at 06:49:38PM +, Chris Wilson wrote:
> > Quoting Stanislav Lisovskiy (2018-11-13 07:45:02)
> > > @@ -408,6 +424,9 @@ void sna_video_textured_setup(struct sna *sna,
> > > ScreenPtr screen)
> > > } else if (sna->kgem.gen < 040) {
> > > adaptor->nImages = ARRAY_SIZE(gen3_Images);
> > > adaptor->pImages = (XvImageRec *)gen3_Images;
> > > + } else if (sna->kgem.gen >= 0110) {
> > > + adaptor->nImages = ARRAY_SIZE(gen9_Images);
> > > + adaptor->pImages = (XvImageRec *)gen9_Images;
> > > } else {
> > > adaptor->nImages = ARRAY_SIZE(gen4_Images);
> > > adaptor->pImages = (XvImageRec *)gen4_Images;
> >
> > Grr. Aside from the minor nits, ok. Ville?
>
> Yeah. Seems good enough. For both
> Reviewed-by: Ville Syrjälä
Ta, thanks for the patches.
To gitlab.freedesktop.org:xorg/driver/xf86-video-intel.git
0932a6b3..746ab3bb master -> master
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: reverse uninit order
On Tue, Nov 13, 2018 at 10:31:25PM +0200, Jani Nikula wrote:
> On Tue, 13 Nov 2018, Lucas De Marchi wrote:
> > Bspec 21257 says "DDIA PHY is the comp master, so it must
> > not be un-initialized if other combo PHYs are in use". Here
> > we are shutting down all phys, so it's not strictly required.
> > However let's be consistent on deinitializing things in the
> > reversed order we initialized them.
> >
> > v2: simplify protection for enum port being unsigned in future
> >
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/intel_combo_phy.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
> > b/drivers/gpu/drm/i915/intel_combo_phy.c
> > index 49f3a533860d..62939df048d7 100644
> > --- a/drivers/gpu/drm/i915/intel_combo_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_combo_phy.c
> > @@ -9,6 +9,10 @@
> > for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
> > for_each_if(intel_port_is_combophy(__dev_priv, __port))
> >
> > +#define for_each_combo_port_rev(__dev_priv, __port) \
>
> The list.h list macros use _reverse suffix for reverse traversal. I
> think we can afford to spend the extra letters here too.
I followed what we do on other for_each macro:
for_each_power_well_rev
for_each_power_domain_well_rev
Should those be reverse as well?
Lucas De Marchi
>
> BR,
> Jani.
>
> > + for ((__port) = I915_MAX_PORTS; (__port)-- > PORT_A;) \
> > + for_each_if(intel_port_is_combophy(__dev_priv, __port))
> > +
> > enum {
> > PROCMON_0_85V_DOT_0,
> > PROCMON_0_95V_DOT_0,
> > @@ -232,7 +236,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
> > *dev_priv)
> > {
> > enum port port;
> >
> > - for_each_combo_port(dev_priv, port) {
> > + for_each_combo_port_rev(dev_priv, port) {
> > u32 val;
> >
> > if (!icl_combo_phy_verify_state(dev_priv, port))
>
> --
> Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: reverse uninit order
On Tue, 13 Nov 2018, Lucas De Marchi wrote:
> On Tue, Nov 13, 2018 at 10:31:25PM +0200, Jani Nikula wrote:
>> On Tue, 13 Nov 2018, Lucas De Marchi wrote:
>> > Bspec 21257 says "DDIA PHY is the comp master, so it must
>> > not be un-initialized if other combo PHYs are in use". Here
>> > we are shutting down all phys, so it's not strictly required.
>> > However let's be consistent on deinitializing things in the
>> > reversed order we initialized them.
>> >
>> > v2: simplify protection for enum port being unsigned in future
>> >
>> > Signed-off-by: Lucas De Marchi
>> > ---
>> > drivers/gpu/drm/i915/intel_combo_phy.c | 6 +-
>> > 1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
>> > b/drivers/gpu/drm/i915/intel_combo_phy.c
>> > index 49f3a533860d..62939df048d7 100644
>> > --- a/drivers/gpu/drm/i915/intel_combo_phy.c
>> > +++ b/drivers/gpu/drm/i915/intel_combo_phy.c
>> > @@ -9,6 +9,10 @@
>> >for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
>> >for_each_if(intel_port_is_combophy(__dev_priv, __port))
>> >
>> > +#define for_each_combo_port_rev(__dev_priv, __port) \
>>
>> The list.h list macros use _reverse suffix for reverse traversal. I
>> think we can afford to spend the extra letters here too.
>
> I followed what we do on other for_each macro:
> for_each_power_well_rev
> for_each_power_domain_well_rev
>
> Should those be reverse as well?
I think so yes.
BR,
Jani.
>
> Lucas De Marchi
>
>>
>> BR,
>> Jani.
>>
>> > + for ((__port) = I915_MAX_PORTS; (__port)-- > PORT_A;) \
>> > + for_each_if(intel_port_is_combophy(__dev_priv, __port))
>> > +
>> > enum {
>> >PROCMON_0_85V_DOT_0,
>> >PROCMON_0_95V_DOT_0,
>> > @@ -232,7 +236,7 @@ void icl_combo_phys_uninit(struct drm_i915_private
>> > *dev_priv)
>> > {
>> >enum port port;
>> >
>> > - for_each_combo_port(dev_priv, port) {
>> > + for_each_combo_port_rev(dev_priv, port) {
>> >u32 val;
>> >
>> >if (!icl_combo_phy_verify_state(dev_priv, port))
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 6/7] drm/i915: Introduce subplatform concept
On Tue, 13 Nov 2018, Tvrtko Ursulin wrote:
> On 13/11/2018 11:40, Jani Nikula wrote:
>> On Mon, 12 Nov 2018, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> Introduce subplatform mask to eliminate throughout the code devid checking
>>> sprinkle, mostly courtesy of IS_*_UL[TX] macros.
>>>
>>> Subplatform mask initialization is done at runtime device info init.
>>
>> I kind of like the concept, and I like the centralization of devid
>> checks in one function, but I've always wanted to take this to one step
>> further: only specify device ids in i915_pciids.h, and *nowhere* else.
>>
>> It's perhaps too much duplication to create a device info for all these
>> variants, but I think it would be possible to make the subplatform info
>> table driven using macros defined in i915_pciids.h.
>
> It would be much nicer, but how would you do it? Perhaps my imagination
> is just strong enough today.
So here's an idea.
>
> Simply by splitting the id's into subplatform parts, for instance where
> we have today:
>
> #define INTEL_BDW_GT1_IDS(info) \
> INTEL_VGA_DEVICE(0x1602, info), /* GT1 ULT */ \
> INTEL_VGA_DEVICE(0x1606, info), /* GT1 ULT */ \
> INTEL_VGA_DEVICE(0x160B, info), /* GT1 Iris */ \
> INTEL_VGA_DEVICE(0x160E, info), /* GT1 ULX */ \
> INTEL_VGA_DEVICE(0x160A, info), /* GT1 Server */ \
> INTEL_VGA_DEVICE(0x160D, info) /* GT1 Workstation */
>
> We'd split to:
>
> #define INTEL_BDW_GT1_ULT_IDS(info) \
> INTEL_VGA_DEVICE(0x1602, info), /* GT1 ULT */ \
> INTEL_VGA_DEVICE(0x1606, info), /* GT1 ULT */ \
>
> #define INTEL_BDW_GT1_ULX_IDS(info) \
> INTEL_VGA_DEVICE(0x160E, info), /* GT1 ULX */ \
So far so good.
>
> #define INTEL_BDW_GT1_IDS(info) \
> INTEL_VGA_DEVICE(0x160B, info), /* GT1 Iris */ \
> INTEL_VGA_DEVICE(0x160A, info), /* GT1 Server */ \
> INTEL_VGA_DEVICE(0x160D, info) /* GT1 Workstation */
Now include INTEL_BDW_GT1_ULT_IDS(info) and INTEL_BDW_GT1_ULX_IDS(info)
to the above...
>
> Then in i915_pci.c, instead of:
>
> ...
> INTEL_BDW_GT1_IDS(&intel_broadwell_gt1_info),
> ...
>
> We'd have:
>
> ...
> INTEL_BDW_GT1_ULT_IDS(&intel_broadwell_gt1_info),
> INTEL_BDW_GT1_ULX_IDS(&intel_broadwell_gt1_info),
> INTEL_BDW_GT1_IDS(&intel_broadwell_gt1_info),
> ...
...so you don't need to make this change at all. But that's a minor
detail.
> And a separate table to map the id's to subplatform values.
>
> Hmm, but we would probably need to extrac the id's from the
> INTEL_BDW1_GT_IDS like macros so they can be used in this second site
> without the info parameter. Something like the trick for device info
> flags, but can it be made to generate a macro? I think not..
Are we shy of macro magic? Pfft.
#undef INTEL_VGA_DEVICE
#define INTEL_VGA_DEVICE(id, info) (id)
static const u32 bdw_ult_ids[] = {
INTEL_BDW_GT1_ULT_IDS(0),
};
static const u32 bdw_ulx_ids[] = {
INTEL_BDW_GT1_ULX_IDS(0),
};
#undef INTEL_VGA_DEVICE
Now you can add another mapping on top with pointers to similar arrays
as above and corresponding subplatform bits. Just need to order the code
to not clobber the real INTEL_VGA_DEVICE needs.
We don't need to split the ult/ulx tables by platform either if we only
care about the subplatform ult/ulx here, just need to remember add all
ult/ulx in corresponding arrays.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: Force background color to black for gen9+
We don't yet allow userspace to control the CRTC background color, but
we should manually program the color to black to ensure the BIOS didn't
leave us with some other color. We should also set the pipe gamma and
pipe CSC bits so that the background color goes through the same color
management transformations that a plane with black pixels would.
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
We may want to land this patch before the rest of the series since it's
still valuable even without the new ABI the rest of the series adds.
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 18 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe4b913e46ac..b92a721c9bcb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5662,6 +5662,12 @@ enum {
#define PIPEMISC_DITHER_TYPE_SP (0 << 2)
#define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
+/* Skylake+ pipe bottom (background) color */
+#define _SKL_CANVAS_A 0x70034
+#define SKL_CANVAS_GAMMA_ENABLE (1 << 31)
+#define SKL_CANVAS_CSC_ENABLE(1 << 30)
+#define SKL_CANVAS(pipe) _MMIO_PIPE2(pipe, _SKL_CANVAS_A)
+
#define VLV_DPFLIPSTAT _MMIO(VLV_DISPLAY_BASE +
0x70028)
#define PIPEB_LINE_COMPARE_INT_EN(1 << 29)
#define PIPEB_HLINE_INT_EN (1 << 28)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 132e978227fb..1d089d93d88b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3868,6 +3868,15 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
else if (old_crtc_state->pch_pfit.enabled)
ironlake_pfit_disable(old_crtc_state);
}
+
+ /*
+* We don't (yet) allow userspace to control the pipe background color,
+* so force it to black, but apply pipe gamma and CSC so that its
+* handling will match how we program our planes.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ I915_WRITE(SKL_CANVAS(crtc->pipe),
+ SKL_CANVAS_GAMMA_ENABLE | SKL_CANVAS_CSC_ENABLE);
}
static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -15356,6 +15365,15 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
plane->base.type != DRM_PLANE_TYPE_PRIMARY)
intel_plane_disable_noatomic(crtc, plane);
}
+
+ /*
+* Disable any background color set by the BIOS, but enable the
+* gamma and CSC to match how we program our planes.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ I915_WRITE(SKL_CANVAS(crtc->pipe),
+ SKL_CANVAS_GAMMA_ENABLE |
+ SKL_CANVAS_CSC_ENABLE);
}
/* Adjust the state of the output pipe according to whether we
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/3] CRTC background color
This is a second revision of the series previously posted here: https://lists.freedesktop.org/archives/intel-gfx/2018-October/178202.html As noted before, this functionality adds new ABI so we need a userspace consumer ready before we merge the kernel work. My understanding is that some of the folks involved with ChromeOS are looking at this and that there's a ChromeOS userspace review happening at https://chromium-review.googlesource.com/c/chromium/src/+/1278858 Since there are a few Intel-specific background color changes that we want to make independently of the new ABI, I've separated those out into a new patch #1; we may want to consider landing that patch before the rest of the series since it fixes an inconsistency in how we currently program our hardware. On the i915-side of things, this series only deals with gen9+ at the moment. It looks like CHV may also have support for background color functionality, but I couldn't find the register layout details for that platform, so I haven't added support for it yet. Cc: dri-de...@lists.freedesktop.org Cc: Wei C Li Cc: Sean Paul Cc: Ville Syrjälä Matt Roper (3): drm/i915: Force background color to black for gen9+ drm: Add CRTC background color property (v2) drm/i915/gen9+: Add support for pipe background color (v2) drivers/gpu/drm/drm_atomic_state_helper.c | 1 + drivers/gpu/drm/drm_atomic_uapi.c | 5 drivers/gpu/drm/drm_blend.c | 21 ++--- drivers/gpu/drm/drm_mode_config.c | 6 + drivers/gpu/drm/i915/i915_debugfs.c | 9 +++ drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_display.c | 39 +++ include/drm/drm_blend.h | 1 + include/drm/drm_crtc.h| 17 ++ include/drm/drm_mode_config.h | 5 include/uapi/drm/drm_mode.h | 26 + 11 files changed, 133 insertions(+), 3 deletions(-) -- 2.14.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm: Add CRTC background color property (v2)
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.
To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value. Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier
to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and
value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Cc: Sean Paul
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
drivers/gpu/drm/drm_atomic_uapi.c | 5 +
drivers/gpu/drm/drm_blend.c | 21 ++---
drivers/gpu/drm/drm_mode_config.c | 6 ++
include/drm/drm_blend.h | 1 +
include/drm/drm_crtc.h| 17 +
include/drm/drm_mode_config.h | 5 +
include/uapi/drm/drm_mode.h | 26 ++
8 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 3ba996069d69..2f8c55668089 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -101,6 +101,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
state->planes_changed = false;
state->connectors_changed = false;
state->color_mgmt_changed = false;
+ state->bgcolor_changed = false;
state->zpos_changed = false;
state->commit = NULL;
state->event = NULL;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 86ac33922b09..b95a55a778e2 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -467,6 +467,9 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == config->bgcolor_property) {
+ state->bgcolor = val;
+ state->bgcolor_changed = true;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -499,6 +502,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->bgcolor_property)
+ *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 0c78ca386cbe..7c73cb83874a 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,16 @@
* plane does not expose the "alpha" property, then this is
* assumed to be 1.0
*
- * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
+ * The property extensions described above all apply to the plane. Drivers
+ * may also expose the following crtc property extension:
+ *
+ * bgcolor:
+ * Background color is setup with drm_crtc_add_bgcolor_property(). It
+ * controls the RGB color of a full-screen, fully-opaque layer that exists
+ * below all planes. This color will be used for pixels not covered by
+ * any plane and may also be blended with plane contents as allowed by a
+ * plane's alpha values. The background color defaults to black, and is
+ * assumed to be black for drivers that do not expose this property.
*/
/**
@@ -593,3 +600,11 @@ int drm_plane_create_blend_mode_property(struct drm_plane
*plane,
return 0;
}
EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
+
+void drm_crtc_add_bgcolor_property(struct drm_crtc *crtc)
+{
+ drm_object_attach_property(&crtc->base,
+ crtc->dev->mode_config.bgcolor_property,
+ drm_rgba(16, 0, 0, 0, 0x));
+}
[Intel-gfx] [PATCH v2 3/3] drm/i915/gen9+: Add support for pipe background color (v2)
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready to
go in. (Ville)
- Change a temporary variable name to be more consistent with
other similar functions. (Ville)
- Change register name to SKL_CANVAS for consistency with the
CHV_CANVAS register.
Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +
drivers/gpu/drm/i915/intel_display.c | 35 ---
2 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 670db5073d70..1f2a19e6ec79 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3254,6 +3254,15 @@ static int i915_display_info(struct seq_file *m, void
*unused)
intel_plane_info(m, crtc);
}
+ if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+ uint64_t background = pipe_config->base.bgcolor;
+
+ seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
b=%x\n",
+ DRM_RGBA_RED(background, 10),
+ DRM_RGBA_GREEN(background, 10),
+ DRM_RGBA_BLUE(background, 10));
+ }
+
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
yesno(!crtc->cpu_fifo_underrun_disabled),
yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1d089d93d88b..e7a759e0c021 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3834,6 +3834,27 @@ void intel_finish_reset(struct drm_i915_private
*dev_priv)
clear_bit(I915_RESET_MODESET, &dev_priv->gpu_error.flags);
}
+static void skl_update_background_color(const struct intel_crtc_state *cstate)
+{
+ struct intel_crtc *crtc = to_intel_crtc(cstate->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ uint64_t propval = cstate->base.bgcolor;
+ uint32_t tmp;
+
+ /* Hardware is programmed with 10 bits of precision */
+ tmp = DRM_RGBA_RED(propval, 10) << 20
+ | DRM_RGBA_GREEN(propval, 10) << 10
+ | DRM_RGBA_BLUE(propval, 10);
+
+ /*
+* Set CSC and gamma for bottom color to ensure background pixels
+* receive the same color transformations as plane content.
+*/
+ tmp |= SKL_CANVAS_CSC_ENABLE | SKL_CANVAS_GAMMA_ENABLE;
+
+ I915_WRITE_FW(SKL_CANVAS(crtc->pipe), tmp);
+}
+
static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
const struct intel_crtc_state
*new_crtc_state)
{
@@ -3869,14 +3890,8 @@ static void intel_update_pipe_config(const struct
intel_crtc_state *old_crtc_sta
ironlake_pfit_disable(old_crtc_state);
}
- /*
-* We don't (yet) allow userspace to control the pipe background color,
-* so force it to black, but apply pipe gamma and CSC so that its
-* handling will match how we program our planes.
-*/
if (INTEL_GEN(dev_priv) >= 9)
- I915_WRITE(SKL_CANVAS(crtc->pipe),
- SKL_CANVAS_GAMMA_ENABLE | SKL_CANVAS_CSC_ENABLE);
+ skl_update_background_color(new_crtc_state);
}
static void intel_fdi_normal_train(struct intel_crtc *crtc)
@@ -10896,6 +10911,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
crtc_state->planes_changed = true;
}
+ if (crtc_state->bgcolor_changed)
+ pipe_config->update_pipe = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(pipe_config);
@@ -14035,6 +14053,9 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
+ if (INTEL_GEN(dev_priv) >= 9)
+ drm_crtc_add_bgcolor_property(&intel_crtc->base);
+
return 0;
fail:
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/kms_crtc_background_color: overhaul for latest ABI proposal (v2)
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them. However the
corresponding IGT test did get merged and has basically been dead code
ever since.
A couple years later we may finally be getting closer to landing the
kernel patches (there's some interest in this functionality now from
both the ChromeOS and Weston camps), so lets update the IGT test to
match the latest proposed ABI, and to remove some of the cruft from the
original test that wouldn't actually work.
It's worth noting that we don't seem to be able to test this feature
with CRC's. Originally we wanted to draw a color into a plane's FB
(with Cairo) and then compare the CRC to turning off all planes and just
setting the CRTC background to the same color. However the precision
and rounding of the color components causes the CRC's to come out
differently, even though the end result is visually identical. So at
the moment this test is mainly useful for visual inspection in
interactive mode.
v2:
- Swap red and blue ordering in property value to reflect change
in v2 of kernel series.
Cc: igt-...@lists.freedesktop.org
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 2 +-
tests/kms_crtc_background_color.c | 221 --
2 files changed, 120 insertions(+), 103 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index d806ccc1..33d6a6fb 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -180,7 +180,7 @@ const char * const
igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
};
const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
- [IGT_CRTC_BACKGROUND] = "background_color",
+ [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
[IGT_CRTC_CTM] = "CTM",
[IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
[IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
diff --git a/tests/kms_crtc_background_color.c
b/tests/kms_crtc_background_color.c
index 3df3401f..e990ecfa 100644
--- a/tests/kms_crtc_background_color.c
+++ b/tests/kms_crtc_background_color.c
@@ -25,164 +25,181 @@
#include "igt.h"
#include
-
IGT_TEST_DESCRIPTION("Test crtc background color feature");
+/*
+ * The original idea was to paint a desired color into a full-screen primary
+ * plane and then compare that CRC with turning off all planes and setting the
+ * CRTC background to the same color. Unforunately, the rounding and precision
+ * of color values as rendered by cairo vs created by the display controller
+ * are slightly different and give different CRC's, even though they're
+ * visually identical.
+ *
+ * Since we can't really use CRC's for testing, this test is mainly useful for
+ * visual inspection in interactive mode at the moment.
+ */
+
typedef struct {
int gfx_fd;
- igt_display_t display;
- struct igt_fb fb;
- igt_crc_t ref_crc;
- igt_pipe_crc_t *pipe_crc;
+ igt_output_t *output;
+ drmModeModeInfo *mode;
} data_t;
-#define BLACK 0x00 /* BGR 8bpc */
-#define CYAN 0x00 /* BGR 8bpc */
-#define PURPLE 0xFF00FF /* BGR 8bpc */
-#define WHITE 0xFF /* BGR 8bpc */
-
-#define BLACK640x /* BGR 16bpc */
-#define CYAN64 0x /* BGR 16bpc */
-#define PURPLE64 0x /* BGR 16bpc */
-#define YELLOW64 0x /* BGR 16bpc */
-#define WHITE640x /* BGR 16bpc */
-#define RED64 0x /* BGR 16bpc */
-#define GREEN640x /* BGR 16bpc */
-#define BLUE64 0x /* BGR 16bpc */
+/*
+ * Local copy of proposed kernel uapi
+ */
+static inline __u64
+local_rgba(__u8 bpc, __u16 red, __u16 green, __u16 blue, __u16 alpha)
+{
+ int msb_shift = 16 - bpc;
+ return (__u64)alpha << msb_shift << 48 |
+ (__u64)red << msb_shift << 32 |
+ (__u64)green << msb_shift << 16 |
+ (__u64)blue << msb_shift;
+}
+#define LOCAL_RGBA_BLUE(c, numbits) (__u16)((c & 0xull) >>
(16-numbits))
+#define LOCAL_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >>
(32-numbits))
+#define LOCAL_RGBA_RED(c, numbits) (__u16)((c & 0xull<<32) >>
(48-numbits))
+#define LOCAL_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >>
(64-numbits))
+
+
+/* 8bpc values */
+#define BLACK local_rgba(8,0,0,0, 0xff)
+#define REDlocal_rgba(8, 0xff,0,0, 0xff)
+#define GREEN local_rgba(8,0, 0xff,0, 0xff)
+#define BLUE local_rgba(8,0,0, 0xff, 0xff)
+#define YELLOW local_rgba(8, 0xff, 0xff,0, 0xff)
+#define WHITE local_rgba(8, 0xff, 0xff, 0xff, 0xff)
+
+/* 16bpc values */
+#define BLACK64local_rgba(16, 0, 0, 0, 0x)
+#define RED64 local_rgba(16, 0x, 0, 0, 0x)
+#define GREEN64local_rgba(16, 0,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for CRTC background color (rev2)
== Series Details == Series: CRTC background color (rev2) URL : https://patchwork.freedesktop.org/series/50834/ State : warning == Summary == $ dim checkpatch origin/drm-tip 99a0ae2cbae8 drm/i915: Force background color to black for gen9+ a25e43dadb92 drm: Add CRTC background color property (v2) -:146: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #146: FILE: include/drm/drm_crtc.h:175: + bool bgcolor_changed : 1; -:214: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV) #214: FILE: include/uapi/drm/drm_mode.h:912: +#define DRM_RGBA_BLUE(c, numbits) (__u16)((c & 0xull) >> (16-numbits)) ^ -:214: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to avoid precedence issues #214: FILE: include/uapi/drm/drm_mode.h:912: +#define DRM_RGBA_BLUE(c, numbits) (__u16)((c & 0xull) >> (16-numbits)) -:214: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as '(numbits)' to avoid precedence issues #214: FILE: include/uapi/drm/drm_mode.h:912: +#define DRM_RGBA_BLUE(c, numbits) (__u16)((c & 0xull) >> (16-numbits)) -:215: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #215: FILE: include/uapi/drm/drm_mode.h:913: +#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits)) ^ -:215: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV) #215: FILE: include/uapi/drm/drm_mode.h:913: +#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits)) ^ -:215: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to avoid precedence issues #215: FILE: include/uapi/drm/drm_mode.h:913: +#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits)) -:215: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as '(numbits)' to avoid precedence issues #215: FILE: include/uapi/drm/drm_mode.h:913: +#define DRM_RGBA_GREEN(c, numbits) (__u16)((c & 0xull<<16) >> (32-numbits)) -:216: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #216: FILE: include/uapi/drm/drm_mode.h:914: +#define DRM_RGBA_RED(c, numbits) (__u16)((c & 0xull<<32) >> (48-numbits)) ^ -:216: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV) #216: FILE: include/uapi/drm/drm_mode.h:914: +#define DRM_RGBA_RED(c, numbits) (__u16)((c & 0xull<<32) >> (48-numbits)) ^ -:216: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to avoid precedence issues #216: FILE: include/uapi/drm/drm_mode.h:914: +#define DRM_RGBA_RED(c, numbits) (__u16)((c & 0xull<<32) >> (48-numbits)) -:216: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as '(numbits)' to avoid precedence issues #216: FILE: include/uapi/drm/drm_mode.h:914: +#define DRM_RGBA_RED(c, numbits) (__u16)((c & 0xull<<32) >> (48-numbits)) -:217: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #217: FILE: include/uapi/drm/drm_mode.h:915: +#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits)) ^ -:217: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV) #217: FILE: include/uapi/drm/drm_mode.h:915: +#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits)) ^ -:217: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'c' may be better as '(c)' to avoid precedence issues #217: FILE: include/uapi/drm/drm_mode.h:915: +#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits)) -:217: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'numbits' may be better as '(numbits)' to avoid precedence issues #217: FILE: include/uapi/drm/drm_mode.h:915: +#define DRM_RGBA_ALPHA(c, numbits) (__u16)((c & 0xull<<48) >> (64-numbits)) total: 0 errors, 1 warnings, 15 checks, 143 lines checked 470dfe72d6c8 drm/i915/gen9+: Add support for pipe background color (v2) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_crtc_background_color: overhaul for latest ABI proposal (v2)
On 13/11/2018 23:22, Matt Roper wrote: It's worth noting that we don't seem to be able to test this feature with CRC's. Originally we wanted to draw a color into a plane's FB (with Cairo) and then compare the CRC to turning off all planes and just setting the CRTC background to the same color. However the precision and rounding of the color components causes the CRC's to come out differently, even though the end result is visually identical. So at the moment this test is mainly useful for visual inspection in interactive mode. Hey Matt, Out of curiosity, are the CRCs different only when with 16bpc? Or with 8bpc too? Thanks, - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_crtc_background_color: overhaul for latest ABI proposal (v2)
On Tue, Nov 13, 2018 at 11:43:12PM +, Lionel Landwerlin wrote: > On 13/11/2018 23:22, Matt Roper wrote: > > It's worth noting that we don't seem to be able to test this feature > > with CRC's. Originally we wanted to draw a color into a plane's FB > > (with Cairo) and then compare the CRC to turning off all planes and just > > setting the CRTC background to the same color. However the precision > > and rounding of the color components causes the CRC's to come out > > differently, even though the end result is visually identical. So at > > the moment this test is mainly useful for visual inspection in > > interactive mode. > Hey Matt, > Out of curiosity, are the CRCs different only when with 16bpc? Or with 8bpc > too? Both 8 and 16 give different CRC's. I suspect it's because cairo handles the color values (which get passed as double) slightly differently internally, although I haven't ruled out a slight inaccuracy on the hardware side. Given the alpha problems on gen9/gen10, it wouldn't surprise me if it turns out that our hardware is also treating a 10bpc component of 0x3ff as 0.999 rather than 1.0. Matt > > Thanks, > > - > Lionel > > > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
