[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Convert _print_param to a macro (rev2)
== Series Details == Series: drm/i915: Convert _print_param to a macro (rev2) URL : https://patchwork.freedesktop.org/series/50789/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4968 -> Patchwork_10422 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50789/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_10422 that come from known issues: === IGT changes === Issues hit igt@amdgpu/amd_basic@cs-compute: fi-kbl-8809g: NOTRUN -> FAIL (fdo#108094) igt@amdgpu/amd_prime@amd-to-i915: fi-kbl-8809g: NOTRUN -> FAIL (fdo#107341) igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cfl-8109u: INCOMPLETE (fdo#106070, fdo#108126) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070 fdo#107341 https://bugs.freedesktop.org/show_bug.cgi?id=107341 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#108094 https://bugs.freedesktop.org/show_bug.cgi?id=108094 fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126 == Participating hosts (45 -> 40) == Additional (1): fi-pnv-d510 Missing(6): fi-ilk-m540 fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-ctg-p8600 fi-byt-n2820 == Build changes == * Linux: CI_DRM_4968 -> Patchwork_10422 CI_DRM_4968: 6c3870cc045403bc59ab66ea6ca4bad98114d0a4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10422: a67cd1f0b8b2d1d163f1856451cd98f3dc76440a @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a67cd1f0b8b2 drm/i915: Convert _print_param to a macro == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10422/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 series starting with [1/6] drm/i915/debugfs: Do not print cached information of a disconnected sink
== Series Details ==
Series: series starting with [1/6] drm/i915/debugfs: Do not print cached
information of a disconnected sink
URL : https://patchwork.freedesktop.org/series/50827/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4965_full -> Patchwork_10417_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10417_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10417_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_10417_full:
=== IGT changes ===
Warnings
igt@perf_pmu@rc6:
shard-kbl: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_10417_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
shard-glk: PASS -> DMESG-WARN (fdo#107956)
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_cursor_crc@cursor-128x128-dpms:
shard-apl: PASS -> FAIL (fdo#103232)
igt@kms_cursor_crc@cursor-256x256-onscreen:
shard-glk: PASS -> FAIL (fdo#103232) +1
igt@kms_fbcon_fbt@psr:
shard-skl: NOTRUN -> FAIL (fdo#107882)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
shard-skl: NOTRUN -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
shard-apl: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
shard-glk: PASS -> FAIL (fdo#103167) +3
igt@kms_frontbuffer_tracking@fbc-stridechange:
shard-skl: NOTRUN -> FAIL (fdo#105683)
{igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb}:
shard-skl: NOTRUN -> FAIL (fdo#108145) +1
igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
shard-apl: PASS -> FAIL (fdo#103166)
igt@kms_vblank@pipe-b-wait-busy-hang:
shard-kbl: PASS -> DMESG-WARN (fdo#106107)
igt@perf@blocking:
shard-hsw: PASS -> FAIL (fdo#102252)
igt@perf_pmu@rc6-runtime-pm:
shard-glk: PASS -> FAIL (fdo#105010)
shard-apl: PASS -> FAIL (fdo#105010)
igt@pm_rpm@cursor:
shard-skl: PASS -> INCOMPLETE (fdo#107807)
Possible fixes
igt@gem_ctx_isolation@vecs0-s3:
shard-skl: INCOMPLETE (fdo#107773, fdo#104108) -> PASS
igt@kms_busy@extended-modeset-hang-newfb-render-b:
shard-kbl: DMESG-WARN (fdo#107956) -> PASS
igt@kms_cursor_crc@cursor-256x256-random:
shard-apl: FAIL (fdo#103232) -> PASS +1
igt@kms_cursor_crc@cursor-64x64-dpms:
shard-glk: FAIL (fdo#103232) -> PASS +1
igt@kms_cursor_legacy@cursora-vs-flipa-toggle:
shard-glk: DMESG-WARN (fdo#105763, fdo#106538) -> PASS
igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled:
shard-skl: FAIL (fdo#103184) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt:
shard-glk: FAIL (fdo#103167) -> PASS +3
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
shard-apl: FAIL (fdo#103167) -> PASS +1
igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
shard-glk: FAIL (fdo#103166) -> PASS +1
igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
shard-apl: FAIL (fdo#103166) -> PASS +2
igt@kms_setmode@basic:
shard-kbl: FAIL (fdo#99912) -> PASS
igt@pm_rpm@pc8-residency:
shard-skl: INCOMPLETE (fdo#107807) -> SKIP
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
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#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184
fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010
fdo#105683 https://bugs.freedesktop.org/show_bug.cgi?id=105683
fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
fdo#106107 https://bugs.freedesktop.org/show_bug.cgi?id=106107
fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773
fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807
fdo#107882 https://bugs.freedesktop.org/show_bug.cgi?id=107882
Re: [Intel-gfx] [PATCH v12 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
On Wed, 2018-10-10 at 17:12 -0700, Radhakrishna Sripada wrote:
> Use the newly added "max bpc" connector property to limit pipe bpp.
>
> V3: Use drm_connector_state to access the "max bpc" property
> V4: Initialize the drm property, add suuport to DP(Ville)
> V5: Use the property in the connector and fix CI failure(Ville)
> V6: Use the core function to attach max_bpc property, remove the
> redundant
> clamping of pipe bpp based on connector info
> V7: Fix Checkpatch warnings
> V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
> V12: Fix debug message(Ville)
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
> Cc: Kishore Kadiyala
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_display.c | 48 +-
> --
> drivers/gpu/drm/i915/intel_dp.c | 4 +++
> drivers/gpu/drm/i915/intel_hdmi.c| 5
> 3 files changed, 37 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a145efba9157..a597c4410f5d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10869,30 +10869,38 @@ static void
> intel_modeset_update_connector_atomic_state(struct drm_device *dev)
> drm_connector_list_iter_end(&conn_iter);
> }
>
> -static void
> -connected_sink_compute_bpp(struct intel_connector *connector,
> -struct intel_crtc_state *pipe_config)
> +static int
> +connected_sink_max_bpp(const struct drm_connector_state *conn_state,
> +struct intel_crtc_state *pipe_config)
> {
> - const struct drm_display_info *info = &connector-
> >base.display_info;
> - int bpp = pipe_config->pipe_bpp;
> + int bpp;
> + struct drm_display_info *info = &conn_state->connector-
> >display_info;
>
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp
> constrains\n",
> - connector->base.base.id,
> - connector->base.name);
> + bpp = min(pipe_config->pipe_bpp, conn_state->max_bpc * 3);
>
> - /* Don't use an invalid EDID bpc value */
> - if (info->bpc != 0 && info->bpc * 3 < bpp) {
> - DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID
> reported max of %d\n",
> - bpp, info->bpc * 3);
> - pipe_config->pipe_bpp = info->bpc * 3;
> + switch (conn_state->max_bpc) {
> + case 6 ... 7:
> + pipe_config->pipe_bpp = 6 * 3;
> + case 8 ... 9:
> + pipe_config->pipe_bpp = 8 * 3;
> + break;
> + case 10 ... 11:
> + pipe_config->pipe_bpp = 10 * 3;
> + break;
> + case 12:
> + pipe_config->pipe_bpp = 12 * 3;
> + break;
> + default:
> + return -EINVAL;
> }
Why do we need this assignment here? I mean you have already determined
the minimum value which is stored in bpp, which should be used and then
check again, that it is not equal and only then use it.
Could it be just as simple as this(or I simply misunderstand something
here):
switch (conn_state->max_bpc) {
case 6 ... 7:
bpp = 6 * 3;
...
default:
return -EINVAL;
}
so here we set bpp(instead of pipe_bpp) to correct value or return
EINVAL.
And then we simply assign pipe_bpp to minimum of those and return:
pipe_bpp = min(pipe_config->pipe_bpp, bpp);
return 0;
Also that way get bpp values also check to correspond to the ranges
given in cases labels, while initial expression
min(pipe_config->pipe_bpp, conn_state->max_bpc * 3) could possibly give
7 * 3 but not 6 * 3(as specified in "case 6 .. 7") for
conn_state->max_bpc = 7.
So then there is no need in next additional assignment and check:
>
> - /* Clamp bpp to 8 on screens without EDID 1.4 */
> - if (info->bpc == 0 && bpp > 24) {
> - DRM_DEBUG_KMS("clamping display bpp (was %d) to
> default limit of 24\n",
> - bpp);
> - pipe_config->pipe_bpp = 24;
> + if (bpp != pipe_config->pipe_bpp) {
> + DRM_DEBUG_KMS("Limiting display bpp to %d instead of
> Edid bpp "
> + "%d, requested bpp %d\n", bpp, 3 *
> info->bpc,
> + 3 * conn_state->max_requested_bpc);
> + pipe_config->pipe_bpp = bpp;
> }
> + return 0;
> }
>
> static int
> @@ -10923,8 +10931,8 @@ compute_baseline_pipe_bpp(struct intel_crtc
> *crtc,
> if (connector_state->crtc != &crtc->base)
> continue;
>
> - connected_sink_compute_bpp(to_intel_connector(connec
> tor),
> -pipe_config);
> + if (connected_sink_max_bpp(connector_state,
> pipe_config) < 0)
> + return -EINVAL;
> }
>
> return bpp;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/g
Re: [Intel-gfx] [v1 02/10] drm/i915: get ready of memory for pvmmio
Quoting Xiaolin Zhang (2018-10-11 07:24:19)
> To enable pvmmio feature, we need to prepare one 4K shared page
> which will be accessed by both guest and backend i915 driver.
>
> guest i915 allocate one page memory and then the guest physical address is
> passed 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.
>
> v1: addressed RFC comment to move both shared_page_lock and shared_page
> to i915_virtual_gpu structure
> v0: RFC
>
> Signed-off-by: Xiaolin Zhang
> ---
> drivers/gpu/drm/i915/i915_drv.c| 8
> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> drivers/gpu/drm/i915/i915_pvinfo.h | 24 +++-
> drivers/gpu/drm/i915/i915_vgpu.c | 19 ++-
> 4 files changed, 51 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 19302342..9b25bb7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -987,6 +987,10 @@ 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);
> + dev_priv->vgpu.shared_page = NULL;
> + }
intel_vgpu_(teardown,cleanup,fini)
setting to NULL? fetch_and_zero() if you must, but here it is a little
pointless.
> }
>
> /**
> @@ -1029,6 +1033,10 @@ static int i915_driver_init_mmio(struct
> drm_i915_private *dev_priv)
> return 0;
>
> err_uncore:
> + if (intel_vgpu_active(dev_priv) && dev_priv->vgpu.shared_page) {
> + free_page((unsigned long)dev_priv->vgpu.shared_page);
> + dev_priv->vgpu.shared_page = NULL;
Same again. Remember that shared_page will never be !0 unless active
anyway.
> + }
> intel_uncore_fini(dev_priv);
> err_bridge:
> pci_dev_put(dev_priv->bridge_dev);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d22154a..2c131d4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1345,6 +1345,8 @@ struct i915_virtual_gpu {
> bool active;
> u32 caps;
> u32 pv_caps;
> + spinlock_t shared_page_lock;
> + struct gvt_shared_page *shared_page;
Ugh, be considerate of struct packing and/or cachelines.
> };
>
> /* used in computing the new watermarks state */
> diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
> b/drivers/gpu/drm/i915/i915_pvinfo.h
> index 26709e8..179d558 100644
> --- a/drivers/gpu/drm/i915/i915_pvinfo.h
> +++ b/drivers/gpu/drm/i915/i915_pvinfo.h
> @@ -49,6 +49,24 @@ enum vgt_g2v_type {
> VGT_G2V_MAX,
> };
>
> +struct pv_ppgtt_update {
> + u64 pdp;
> + u64 start;
> + u64 length;
> + u32 cache_level;
> +};
Not used. Only introduce interfaces as they are being used, or just
before.
> +/*
> + * 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 elsp_data[4];
> + u32 reg_addr;
> + u32 disable_irq;
> + struct pv_ppgtt_update pv_ppgtt;
> +};
> +
> #define VGPU_PVMMIO(vgpu) vgpu_vreg_t(vgpu, vgtif_reg(enable_pvmmio))
>
> /*
> @@ -121,8 +139,12 @@ struct vgt_if {
> u32 execlist_context_descriptor_lo;
> u32 execlist_context_descriptor_hi;
> u32 enable_pvmmio;
> + struct {
> + u32 lo;
> + u32 hi;
> + } shared_page_gpa;
>
> - u32 rsv7[0x200 - 25];/* pad to one page */
> + 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 907bbd2..609eefe 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;
> + u64 shared_page_gpa;
Scope.
> BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>
> @@ -91,7 +92,23 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
> dev_priv->vgpu.pv_caps);
> dev_priv->vgpu.pv_caps = __raw_i915_read32(dev_priv,
> vgtif_reg(enable_pvmmio));
> -
> + if (intel_vgpu_active(dev_priv) && dev_priv->vgpu.pv_caps) {
> + 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");
> +
Re: [Intel-gfx] [v1 10/10] drm/i915/gvt: GVTg support ppgtt pvmmio optimization
On 2018年10月11日 14:14, Xiaolin Zhang wrote:
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.
It is possible that Guest VGPU writes the ppgtt entry by using 2M/64K
page mode.
If so, the gvtg should also handle it in PVMMIO mode.
v1: rebase
v0: RFC
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 | 13 +-
3 files changed, 338 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 58e166e..8d3e21a 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++) {
@@ -2767,3 +2815,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;
+
[Intel-gfx] ✓ Fi.CI.IGT: success for CRTC background color
== Series Details ==
Series: CRTC background color
URL : https://patchwork.freedesktop.org/series/50834/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4966_full -> Patchwork_10418_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10418_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10418_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_10418_full:
=== IGT changes ===
Warnings
igt@perf_pmu@rc6:
shard-kbl: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_10418_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_cpu_reloc@full:
shard-skl: NOTRUN -> INCOMPLETE (fdo#108073)
igt@gem_ppgtt@blt-vs-render-ctx0:
shard-skl: NOTRUN -> TIMEOUT (fdo#108039)
igt@kms_atomic_transition@2x-modeset-transitions-nonblocking-fencing:
shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359)
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
shard-kbl: PASS -> DMESG-WARN (fdo#107956)
igt@kms_concurrent@pipe-b:
shard-hsw: PASS -> DMESG-WARN (fdo#102614)
igt@kms_fbcon_fbt@psr:
shard-skl: NOTRUN -> FAIL (fdo#107882)
igt@kms_flip@flip-vs-expired-vblank:
shard-glk: PASS -> FAIL (fdo#105363, fdo#102887)
igt@kms_flip@plain-flip-ts-check:
shard-skl: PASS -> FAIL (fdo#100368)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
shard-skl: NOTRUN -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
shard-apl: PASS -> FAIL (fdo#103167) +3
igt@kms_frontbuffer_tracking@fbc-1p-rte:
shard-glk: PASS -> FAIL (fdo#103167, fdo#105682)
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
shard-glk: PASS -> FAIL (fdo#103167) +4
igt@kms_frontbuffer_tracking@fbc-stridechange:
shard-skl: NOTRUN -> FAIL (fdo#105683)
igt@kms_plane@pixel-format-pipe-c-planes:
shard-skl: NOTRUN -> DMESG-FAIL (fdo#103166, fdo#106885)
{igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb}:
shard-skl: NOTRUN -> FAIL (fdo#108145)
igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
shard-apl: PASS -> FAIL (fdo#103166) +1
igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
shard-glk: PASS -> FAIL (fdo#103166)
igt@pm_rpm@sysfs-read:
shard-skl: NOTRUN -> INCOMPLETE (fdo#107807)
igt@pm_rpm@system-suspend-devices:
shard-skl: PASS -> INCOMPLETE (fdo#107807)
Possible fixes
igt@kms_available_modes_crc@available_mode_test_crc:
shard-apl: FAIL (fdo#106641) -> PASS
igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
shard-glk: FAIL (fdo#108145) -> PASS
igt@kms_cursor_crc@cursor-128x128-random:
shard-apl: FAIL (fdo#103232) -> PASS +1
igt@kms_cursor_crc@cursor-64x64-sliding:
shard-glk: FAIL (fdo#103232) -> PASS
igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
shard-glk: DMESG-WARN (fdo#105763, fdo#106538) -> PASS +1
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
shard-apl: FAIL (fdo#103167) -> PASS +1
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
shard-glk: FAIL (fdo#103167) -> PASS +3
igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-cpu:
shard-glk: DMESG-FAIL (fdo#106538) -> PASS
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-apl: FAIL (fdo#103166) -> PASS +1
igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
shard-glk: FAIL (fdo#103166) -> PASS +3
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
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#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#105682 https://bugs.freedesktop.org/show_bug.cgi?id=105682
fdo#105683 https://bugs
Re: [Intel-gfx] [PATCH v7 1/5] drm/atomic_helper: Disallow new modesets on unregistered connectors
On Tue, Oct 09, 2018 at 08:20:27PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 08, 2018 at 07:24:30PM -0400, Lyude Paul wrote:
> > With the exception of modesets which would switch the DPMS state of a
> > connector from on to off, we want to make sure that we disallow all
> > modesets which would result in enabling a new monitor or a new mode
> > configuration on a monitor if the connector for the display in question
> > is no longer registered. This allows us to stop userspace from trying to
> > enable new displays on connectors for an MST topology that were just
> > removed from the system, without preventing userspace from disabling
> > DPMS on those connectors.
> >
> > Changes since v5:
> > - Fix typo in comment, nothing else
> >
> > Signed-off-by: Lyude Paul
> > Reviewed-by: Daniel Vetter
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 21 -
> > 1 file changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 6f66777dca4b..e6a2cf72de5e 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -319,6 +319,26 @@ update_connector_routing(struct drm_atomic_state
> > *state,
> > return 0;
> > }
> >
> > + crtc_state = drm_atomic_get_new_crtc_state(state,
> > + new_connector_state->crtc);
> > + /*
> > +* For compatibility with legacy users, we want to make sure that
> > +* we allow DPMS On->Off modesets on unregistered connectors. Modesets
> > +* which would result in anything else must be considered invalid, to
> > +* avoid turning on new displays on dead connectors.
> > +*
> > +* Since the connector can be unregistered at any point during an
> > +* atomic check or commit, this is racy. But that's OK: all we care
> > +* about is ensuring that userspace can't do anything but shut off the
> > +* display on a connector that was destroyed after its been notified,
> > +* not before.
> > +*/
> > + if (!READ_ONCE(connector->registered) && crtc_state->active) {
> > + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
> > +connector->base.id, connector->name);
> > + return -EINVAL;
> > + }
>
> This broke my ilk (and presumably snb-bdw as well).
>
> [ 25.593121] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]]
> Updating routing for [CONNECTOR:55:eDP-1]
> [ 25.593131] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]]
> [CONNECTOR:55:eDP-1] is not registered
> [ 25.593133] [ cut here ]
> [ 25.593134] Could not determine valid watermarks for inherited state
> [ 25.593212] WARNING: CPU: 0 PID: 3060 at
> ../drivers/gpu/drm/i915/intel_display.c:14983
> intel_modeset_init+0x12cf/0x1980 [i915]
>
> Also I can't see that any of the repostings of this has undergone the
> full CI run (just BAT results are visible). Not sure why that is.
> Not that the full run would have caught this because we unwisely
> load the module before the tests start. Which means any failures
> during initial readout/takeover will not be flagged :(
Ugh, so we need a special bool for "unplugged", to differentiate it from
the "it's real, but not yet registered because the driver isn't fully
loaded yet" case.
-Daniel
>
> > +
> > funcs = connector->helper_private;
> >
> > if (funcs->atomic_best_encoder)
> > @@ -363,7 +383,6 @@ update_connector_routing(struct drm_atomic_state *state,
> >
> > set_best_encoder(state, new_connector_state, new_encoder);
> >
> > - crtc_state = drm_atomic_get_new_crtc_state(state,
> > new_connector_state->crtc);
> > crtc_state->connectors_changed = true;
> >
> > DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on
> > [CRTC:%d:%s]\n",
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors
On Wed, Oct 10, 2018 at 09:32:24PM +0300, Ville Syrjälä wrote: > On Tue, Oct 09, 2018 at 04:44:24PM -0400, Lyude Paul wrote: > > It appears when testing my previous fix for some of the legacy > > modesetting issues with MST, I misattributed some kernel splats that > > started appearing on my machine after a rebase as being from upstream. > > But it appears they actually came from my patch series: > > > > [2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > > Updating routing for [CONNECTOR:65:eDP-1] > > [2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] > > [CONNECTOR:65:eDP-1] is not registered > > [2.980516] [ cut here ] > > [2.980519] Could not determine valid watermarks for inherited state > > [2.980553] WARNING: CPU: 3 PID: 551 at > > drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 > > [i915] > > [2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) > > syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl > > x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse > > i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm > > thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd > > xhci_pci xhci_hcd > > [2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O > >4.19.0-rc7Lyude-Test+ #1 > > [2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW > > (1.27 ) 11/10/2016 > > [2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] > > [2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 > > 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 > > <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 > > [2.980611] RSP: 0018:c9287988 EFLAGS: 00010282 > > [2.980614] RAX: RBX: 88031b488000 RCX: > > 0006 > > [2.980617] RDX: 0007 RSI: 0086 RDI: > > 880321ad54d0 > > [2.980620] RBP: c9287a10 R08: 040a R09: > > 0065 > > [2.980623] R10: 88030ebb8f00 R11: 81416590 R12: > > 88031b488000 > > [2.980626] R13: 88031b4883a0 R14: c92879a8 R15: > > 880319099800 > > [2.980630] FS: 7f475620d180() GS:880321ac() > > knlGS: > > [2.980633] CS: 0010 DS: ES: CR0: 80050033 > > [2.980636] CR2: 7f9ef28018a0 CR3: 00031b72c001 CR4: > > 003606e0 > > [2.980639] DR0: DR1: DR2: > > > > [2.980642] DR3: DR6: fffe0ff0 DR7: > > 0400 > > [2.980645] Call Trace: > > [2.980675] i915_driver_load+0xb0e/0xdc0 [i915] > > [2.980681] ? kernfs_add_one+0xe7/0x130 > > [2.980709] i915_pci_probe+0x46/0x60 [i915] > > [2.980715] pci_device_probe+0xd4/0x150 > > [2.980719] really_probe+0x243/0x3b0 > > [2.980722] driver_probe_device+0xba/0x100 > > [2.980726] __driver_attach+0xe4/0x110 > > [2.980729] ? driver_probe_device+0x100/0x100 > > [2.980733] bus_for_each_dev+0x74/0xb0 > > [2.980736] driver_attach+0x1e/0x20 > > [2.980739] bus_add_driver+0x159/0x230 > > [2.980743] ? 0xa0393000 > > [2.980746] driver_register+0x70/0xc0 > > [2.980749] ? 0xa0393000 > > [2.980753] __pci_register_driver+0x57/0x60 > > [2.980780] i915_init+0x55/0x58 [i915] > > [2.980785] do_one_initcall+0x4a/0x1c4 > > [2.980789] ? do_init_module+0x27/0x210 > > [2.980793] ? kmem_cache_alloc_trace+0x131/0x190 > > [2.980797] do_init_module+0x60/0x210 > > [2.980800] load_module+0x2063/0x22e0 > > [2.980804] ? vfs_read+0x116/0x140 > > [2.980807] ? vfs_read+0x116/0x140 > > [2.980811] __do_sys_finit_module+0xbd/0x120 > > [2.980814] ? __do_sys_finit_module+0xbd/0x120 > > [2.980818] __x64_sys_finit_module+0x1a/0x20 > > [2.980821] do_syscall_64+0x5a/0x110 > > [2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [2.980826] RIP: 0033:0x7f4754e32879 > > [2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 > > 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 > > <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 > > [2.980831] RSP: 002b:7fff43fd97d8 EFLAGS: 0246 ORIG_RAX: > > 0139 > > [2.980834] RAX: ffda RBX: 559a44ca64f0 RCX: > > 7f4754e32879 > > [2.980836] RDX: RSI: 7f475599f4cd RDI: > > 0018 > > [2.980838] RBP: 7f475599f4cd R08: R09: > > > > [2.980839] R10: 0018 R11: 0246 R12: > > > > [2.980841] R13: 559a44c92fd0 R14: 0002 R15: > > > >
Re: [Intel-gfx] [PATCH xf86-video-intel v3 2/2] sna: Added AYUV format support for textured and sprite video adapters.
On Wed, 2018-10-10 at 22:47 +0300, Ville Syrjälä wrote:
> What's this?
>
> > tmp->blt = gen9_render_composite_blt;
> > tmp->box = gen9_render_composite_box;
> > tmp->boxes = gen9_render_composite_boxes__blt;
> > @@ -2784,6 +2804,7 @@ gen9_render_composite_spans(struct sna *sna,
> > tmp->base.u.gen9.wm_kernel =
> > GEN9_WM_KERNEL_OPACITY | !tmp->base.is_affine;
> >
> > + tmp->base.gen9_kernel = GEN9_WM_KERNEL_OPACITY | !tmp-
> > >base.is_affine;
>
> And this?
Thanks for noticing! Those are remains of my own patch when I tried to
fix the flag(running out of kernels) issue myself, then after I figured
out that you have this patch already I applied it, however looks like
for some weird reason, I didn't remove my own duplicate changes.
>
> > tmp->box = gen9_render_composite_spans_box;
> > tmp->boxes = gen9_render_composite_spans_boxes;
> > if (tmp->emit_boxes)
> > @@ -3853,6 +3874,8 @@ static void gen9_emit_video_state(struct sna
> > *sna,
> > src_surf_format[0] =
> > SURFACEFORMAT_B8G8R8X8_UNORM;
> > else if (frame->id == FOURCC_UYVY)
> > src_surf_format[0] =
> > SURFACEFORMAT_YCRCB_SWAPY;
> > + else if (is_ayuv_fourcc(frame->id))
>
> Just frame->id == FOURCC_AYUV?
>
> > + src_surf_format[0] =
> > SURFACEFORMAT_B8G8R8A8_UNORM;
> > else
> > src_surf_format[0] =
> > SURFACEFORMAT_YCRCB_NORMAL;
> >
> > @@ -3903,6 +3926,9 @@ static unsigned select_video_kernel(const
> > struct sna_video *video,
> > case FOURCC_RGB565:
> > return GEN9_WM_KERNEL_VIDEO_RGB;
> >
> > + case FOURCC_AYUV:
> > + return GEN9_WM_KERNEL_VIDEO_PACKED_AYUV_BT601;
>
> Missing the colorspace handling.
>
> > +
> > default:
> > return video->colorspace ?
> > GEN9_WM_KERNEL_VIDEO_PACKED_BT709 :
> > @@ -4080,6 +4106,7 @@ static void gen9_render_fini(struct sna *sna)
> > kgem_bo_destroy(&sna->kgem, sna-
> > >render_state.gen9.general_bo);
> > }
> >
> > +
>
> stray whitespace
>
> > static bool gen9_render_setup(struct sna *sna)
> > {
> > struct gen9_render_state *state = &sna->render_state.gen9;
> > diff --git a/src/sna/sna_render.h b/src/sna/sna_render.h
> > index a4e5b56a..7ae9a0b0 100644
> > --- a/src/sna/sna_render.h
> > +++ b/src/sna/sna_render.h
> > @@ -154,6 +154,7 @@ struct sna_composite_op {
> > uint8_t wm_kernel;
> > } gen9;
> > } u;
> > + unsigned long gen9_kernel;
>
> ?
>
> >
> > void *priv;
> > };
> > @@ -617,6 +618,9 @@ enum {
> > GEN9_WM_KERNEL_VIDEO_NV12_BT709,
> > GEN9_WM_KERNEL_VIDEO_PACKED_BT709,
> >
> > + GEN9_WM_KERNEL_VIDEO_PACKED_AYUV_BT601,
> > + GEN9_WM_KERNEL_VIDEO_PACKED_AYUV_BT709,
> > +
> > GEN9_WM_KERNEL_VIDEO_RGB,
> > GEN9_WM_KERNEL_COUNT
> > };
> > diff --git a/src/sna/sna_video.c b/src/sna/sna_video.c
> > index 55405f81..b3c2bdc6 100644
> > --- a/src/sna/sna_video.c
> > +++ b/src/sna/sna_video.c
> > @@ -281,6 +281,7 @@ sna_video_frame_set_rotation(struct sna_video
> > *video,
> > } else {
> > switch (frame->id) {
> > case FOURCC_RGB888:
> > + case FOURCC_AYUV:
> > if (rotation & (RR_Rotate_90 |
> > RR_Rotate_270)) {
> > frame->pitch[0] = ALIGN((height <<
> > 2), align);
> > frame->size = (int)frame->pitch[0]
> > * width;
> > @@ -584,6 +585,149 @@ sna_copy_packed_data(struct sna_video *video,
> > }
> > }
> >
> > +static void
> > +sna_copy_packed_data_ayuv(struct sna_video *video,
>
> Maybe sna_copy_ayuv_data() ?
>
> > +const struct sna_video_frame *frame,
> > +const uint8_t *buf,
> > +uint8_t *dst)
> > +{
> > + int pitch = frame->width << 2;
> > + const uint8_t *src, *s;
> > + int x, y, w, h;
> > + int i, j;
> > +
> > + if (video->textured) {
> > + /* XXX support copying cropped extents */
> > + x = y = 0;
> > + w = frame->width;
> > + h = frame->height;
> > + } else {
> > + x = frame->image.x1;
> > + y = frame->image.y1;
> > + w = frame->image.x2 - frame->image.x1;
> > + h = frame->image.y2 - frame->image.y1;
> > + }
> > +
> > + src = buf + (y * pitch) + (x << 2);
> > + switch (frame->rotation) {
> > + case RR_Rotate_0:
> > + w <<= 2;
> > + for (i = 0; i < h; i++) {
> > + for (j = 0; j < w; j += 4) {
> > + uint32_t reverse_dw, dw =
> > *((uint32_t*)(&src[i * frame->pitch[0] + j]));
> > + if (!video->textured) {
>
> Maybe just byteswap always to make things work the same way for both
> textured and sprites?
>
> bswap_32() or something?
Definitely, I'll put this to separate function.
>
> > + /*
> > +
[Intel-gfx] ✗ Fi.CI.IGT: failure for tests/kms_crtc_background_color: overhaul for latest ABI proposal
== Series Details ==
Series: tests/kms_crtc_background_color: overhaul for latest ABI proposal
URL : https://patchwork.freedesktop.org/series/50835/
State : failure
== Summary ==
= CI Bug Log - changes from IGT_4672_full -> IGTPW_1935_full =
== Summary - FAILURE ==
Serious unknown changes coming with IGTPW_1935_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_1935_full, 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/50835/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in IGTPW_1935_full:
=== IGT changes ===
Possible regressions
igt@gem_eio@in-flight-suspend:
shard-glk: PASS -> FAIL
Warnings
igt@pm_rc6_residency@rc6-accuracy:
shard-kbl: PASS -> SKIP +1
== Known issues ==
Here are the changes found in IGTPW_1935_full that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_cursor_crc@cursor-128x42-random:
shard-apl: PASS -> FAIL (fdo#103232)
igt@kms_cursor_crc@cursor-64x21-onscreen:
shard-glk: PASS -> FAIL (fdo#103232)
igt@kms_cursor_crc@cursor-64x64-suspend:
shard-kbl: PASS -> FAIL (fdo#103191, fdo#103232)
igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
shard-glk: PASS -> DMESG-WARN (fdo#106538, fdo#105763) +2
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
shard-apl: PASS -> FAIL (fdo#103167) +4
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-blt:
shard-glk: PASS -> DMESG-FAIL (fdo#106538)
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
shard-glk: PASS -> FAIL (fdo#103167) +2
{igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max}:
shard-glk: PASS -> FAIL (fdo#108145)
shard-kbl: PASS -> FAIL (fdo#108145)
shard-apl: PASS -> FAIL (fdo#108145)
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-apl: PASS -> FAIL (fdo#103166) +1
igt@perf@blocking:
shard-hsw: PASS -> FAIL (fdo#102252)
igt@prime_mmap@test_refcounting:
shard-snb: PASS -> INCOMPLETE (fdo#105411)
Possible fixes
igt@kms_available_modes_crc@available_mode_test_crc:
shard-apl: FAIL (fdo#106641) -> PASS
igt@kms_cursor_crc@cursor-128x42-onscreen:
shard-apl: FAIL (fdo#103232) -> PASS +2
igt@kms_cursor_crc@cursor-256x256-sliding:
shard-glk: FAIL (fdo#103232) -> PASS +3
igt@kms_cursor_crc@cursor-64x64-sliding:
shard-kbl: FAIL (fdo#103232) -> PASS
igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
shard-hsw: FAIL (fdo#105767) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
shard-apl: FAIL (fdo#103167) -> PASS
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
shard-glk: FAIL (fdo#103167) -> PASS +1
igt@kms_plane@plane-position-covered-pipe-a-planes:
shard-glk: FAIL (fdo#103166) -> PASS +3
{igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max}:
shard-glk: FAIL (fdo#108145) -> PASS +1
shard-apl: FAIL (fdo#108145) -> PASS
shard-kbl: FAIL (fdo#108145) -> PASS
igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
shard-apl: FAIL (fdo#103166) -> PASS +2
Warnings
igt@kms_cursor_crc@cursor-64x64-suspend:
shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> FAIL
(fdo#103232)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
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#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767
fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641
fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133
== Participating hosts (6 -> 5) ==
Missing(1): shard-skl
== Buil
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
On Wed, Oct 10, 2018 at 05:20:59PM -0700, Deepak Rawat wrote:
> Add DRIVER_VMWGFX to represent vmwgfx device for running igt tests.
>
> v2: Don't remove second virtio_gpu
>
> Signed-off-by: Deepak Rawat
> ---
> lib/drmtest.c | 8
> lib/drmtest.h | 3 +++
> 2 files changed, 11 insertions(+)
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index fee9d33a..9d013a00 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -105,6 +105,11 @@ bool is_i915_device(int fd)
> return __is_device(fd, "i915");
> }
>
> +bool is_vmwgfx_device(int fd)
> +{
> + return __is_device(fd, "vmwg");
> +}
> +
> static bool has_known_intel_chipset(int fd)
> {
> struct drm_i915_getparam gp;
> @@ -206,6 +211,7 @@ static const struct module {
> { DRIVER_VGEM, "vgem" },
> { DRIVER_VIRTIO, "virtio-gpu" },
> { DRIVER_VIRTIO, "virtio_gpu" },
> + { DRIVER_VMWGFX, "vmwgfx" },
> {}
> };
>
> @@ -348,6 +354,8 @@ static const char *chipset_to_str(int chipset)
> return "virtio";
> case DRIVER_AMDGPU:
> return "amdgpu";
> + case DRIVER_VMWGFX:
> + return "vmwgfx";
> case DRIVER_ANY:
> return "any";
> default:
> diff --git a/lib/drmtest.h b/lib/drmtest.h
> index 949865ee..0213fb51 100644
> --- a/lib/drmtest.h
> +++ b/lib/drmtest.h
> @@ -43,6 +43,7 @@
> #define DRIVER_VGEM (1 << 2)
> #define DRIVER_VIRTIO(1 << 3)
> #define DRIVER_AMDGPU(1 << 4)
> +#define DRIVER_VMWGFX(1 << 5)
This seems not needed? For pure generic kms tests I think it'd be great if
we don't have to sprinkle driver-specific checks all over. Which you seem
to achive in your series here.
So not clear why this here is needed?
-Daniel
> /*
> * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> * with vgem as well as a supported driver, you can end up with a
> @@ -80,6 +81,8 @@ void igt_require_intel(int fd);
>
> bool is_i915_device(int fd);
>
> +bool is_vmwgfx_device(int fd);
> +
> /**
> * do_or_die:
> * @x: command
> --
> 2.17.1
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/plane_damage: Integrate kernel selftest test-drm_damage_helper
On Wed, Oct 10, 2018 at 05:21:04PM -0700, Deepak Rawat wrote:
> Call kernel selftest module test-drm_damage_helper from igt.
>
> v2:
> - Add test alphabetically.
> - Add test to meson build.
>
> Cc: ville.syrj...@linux.intel.com
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> Signed-off-by: Deepak Rawat
> ---
> tests/Makefile.sources| 1 +
> tests/drm_plane_damage.c | 10 ++
> tests/igt_command_line.sh | 2 +-
> tests/meson.build | 1 +
> 4 files changed, 13 insertions(+), 1 deletion(-)
> create mode 100644 tests/drm_plane_damage.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 001f1a2b..eae5f39e 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -32,6 +32,7 @@ TESTS_progs = \
> debugfs_test \
> drm_import_export \
> drm_mm \
> + drm_plane_damage \
> drm_read \
> drv_getparams_basic \
> drv_hangman \
> diff --git a/tests/drm_plane_damage.c b/tests/drm_plane_damage.c
> new file mode 100644
> index ..c2b793cc
> --- /dev/null
> +++ b/tests/drm_plane_damage.c
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include "igt.h"
> +#include "igt_kmod.h"
> +
> +IGT_TEST_DESCRIPTION("Basic sanity check of DRM's plane damage helper
> iterator.");
> +
> +igt_main
> +{
> + igt_kselftests("test-drm_damage_helper", NULL, NULL, NULL);
> +}
> diff --git a/tests/igt_command_line.sh b/tests/igt_command_line.sh
> index 8285ba62..621b2cbd 100755
> --- a/tests/igt_command_line.sh
> +++ b/tests/igt_command_line.sh
> @@ -90,7 +90,7 @@ check_test ()
> # Subtest enumeration of kernel selftest launchers depends
> # on the running kernel. If selftests are not enabled,
> # they will output nothing and exit with 0.
> - if [ "$testname" != "drv_selftest" -a "$testname" != "drm_mm"
> ]; then
> + if [ "$testname" != "drv_selftest" -a "$testname" != "drm_mm"
> -a "$testname" != "drm_plane_damage" ]; then
> fail $test
> fi
> fi
> diff --git a/tests/meson.build b/tests/meson.build
> index 697ff515..5acd7aa2 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -9,6 +9,7 @@ test_progs = [
> 'debugfs_test',
> 'drm_import_export',
> 'drm_mm',
> + 'drm_plane_damage',
For future proofing I think it'd be much better if we call this drm_kms or
similar. The individual subtest results will be all exposed, but there's a
bit a problem when we always have to upgrade both igt and the kernel at
the same time. At least with the current CI infrastructure.
I'm also asking the ARM folks to type selftests for the new block_* format
description stuff, so this will come in handy real soon.
-Daniel
> 'drm_read',
> 'drv_getparams_basic',
> 'drv_hangman',
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check ppgtt validity for GVT GEM context
On 2018.10.11 07:23:11 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-10-11 03:45:07)
> > On 2018.10.09 14:08:20 +0800, Xiong Zhang wrote:
> > > The guest couldn't boot up under GVT-g environment as the following call
> > > trace exists:
> > > [ 272.504762] BUG: unable to handle kernel NULL pointer dereference at
> > > 0100
> > > [ 272.504834] Call Trace:
> > > [ 272.504852] execlists_context_pin+0x2b2/0x520 [i915]
> > > [ 272.504869] intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> > > [ 272.504887] intel_vgpu_create_workload+0x3e2/0x570 [i915]
> > > [ 272.504901] intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> > > [ 272.504916] elsp_mmio_write+0xc7/0x130 [i915]
> > > [ 272.504930] intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> > > [ 272.504944] intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> > > [ 272.504947] intel_vgpu_rw+0x22d/0x270 [kvmgt]
> > > [ 272.504949] intel_vgpu_write+0x164/0x1f0 [kvmgt]
> > >
> > > GVT GEM context is created by i915_gem_context_create_gvt() which doesn't
> > > allocate ppgtt. So GVT GEM context structure doesn't have a valid
> > > i915_hw_ppgtt.
> > >
> > > GVT maintain a shadow ppgtt for each guest ppgtt, and attach this shadow
> > > ppgtt to gpu when the corresponding guest ppgtt will be scheduled onto
> > > gpu.
> > > The structure of shadow ppgtt is different from i915_hw_ppgtt, a lot of
> > > gvt
> > > refactor work should be done in order to use i915_hw_ppgtt structure.
> > > So let's fix the regression first.
> > >
> > > Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for
> > > execlists")
> > >
> > > Signed-off-by: Xiong Zhang
> > > ---
> >
> > Chris, any comment? Without this, current gvt breaks on drm tip with kernel
> > oops.
> > Could we fix the regression first then check gvt ctx stub ppgtt handling
> > later?
> > Which would require more change on gvt side, not sure if need any more
> > helper from
> > i915 ppgtt code with a clean fix..
>
> We both thought this wasn't the approach we wanted to take. My position
> is that this leaves the registers ostensibly programmed to garbage.
yeah, I agree that's not ideal, my point is that would bring more changes e.g
gvt ctx create function need to be changed accordingly, etc. and I'm
disappointed why CI didn't catch this in first place, as Terrence has
contributed GVT guest boot test in igt, we need to add that for list patch
checking!
Current gvt nightly test is using this one to kick, we'll see if a quick
mitigation can be made.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
On Thu, Oct 11, 2018 at 11:01:48AM +0200, Daniel Vetter wrote:
> On Wed, Oct 10, 2018 at 05:20:59PM -0700, Deepak Rawat wrote:
> > Add DRIVER_VMWGFX to represent vmwgfx device for running igt tests.
> >
> > v2: Don't remove second virtio_gpu
> >
> > Signed-off-by: Deepak Rawat
> > ---
> > lib/drmtest.c | 8
> > lib/drmtest.h | 3 +++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > index fee9d33a..9d013a00 100644
> > --- a/lib/drmtest.c
> > +++ b/lib/drmtest.c
> > @@ -105,6 +105,11 @@ bool is_i915_device(int fd)
> > return __is_device(fd, "i915");
> > }
> >
> > +bool is_vmwgfx_device(int fd)
> > +{
> > + return __is_device(fd, "vmwg");
> > +}
> > +
> > static bool has_known_intel_chipset(int fd)
> > {
> > struct drm_i915_getparam gp;
> > @@ -206,6 +211,7 @@ static const struct module {
> > { DRIVER_VGEM, "vgem" },
> > { DRIVER_VIRTIO, "virtio-gpu" },
> > { DRIVER_VIRTIO, "virtio_gpu" },
> > + { DRIVER_VMWGFX, "vmwgfx" },
> > {}
> > };
> >
> > @@ -348,6 +354,8 @@ static const char *chipset_to_str(int chipset)
> > return "virtio";
> > case DRIVER_AMDGPU:
> > return "amdgpu";
> > + case DRIVER_VMWGFX:
> > + return "vmwgfx";
> > case DRIVER_ANY:
> > return "any";
> > default:
> > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > index 949865ee..0213fb51 100644
> > --- a/lib/drmtest.h
> > +++ b/lib/drmtest.h
> > @@ -43,6 +43,7 @@
> > #define DRIVER_VGEM(1 << 2)
> > #define DRIVER_VIRTIO (1 << 3)
> > #define DRIVER_AMDGPU (1 << 4)
> > +#define DRIVER_VMWGFX (1 << 5)
>
> This seems not needed? For pure generic kms tests I think it'd be great if
> we don't have to sprinkle driver-specific checks all over. Which you seem
> to achive in your series here.
>
> So not clear why this here is needed?
Loading the .ko needs the name in this array:
> > @@ -206,6 +211,7 @@ static const struct module {
> > { DRIVER_VGEM, "vgem" },
> > { DRIVER_VIRTIO, "virtio-gpu" },
> > { DRIVER_VIRTIO, "virtio_gpu" },
> > + { DRIVER_VMWGFX, "vmwgfx" },
--
Petri Latvala
> -Daniel
>
> > /*
> > * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> > * with vgem as well as a supported driver, you can end up with a
> > @@ -80,6 +81,8 @@ void igt_require_intel(int fd);
> >
> > bool is_i915_device(int fd);
> >
> > +bool is_vmwgfx_device(int fd);
> > +
> > /**
> > * do_or_die:
> > * @x: command
> > --
> > 2.17.1
> >
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v1 03/10] drm/i915: context submission pvmmio optimization
Quoting Xiaolin Zhang (2018-10-11 07:14:05) > 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. > > v1: rebase > v0: RFC > > Signed-off-by: Xiaolin Zhang > --- > drivers/gpu/drm/i915/i915_vgpu.c | 2 ++ > drivers/gpu/drm/i915/intel_lrc.c | 37 - Hint: intel_vgpu_submission.c and go wild. You do not need to emulate execlists at all, an async interface along the lines of guc would strangely enough be more akin to what you want. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check ppgtt validity for GVT GEM context
Quoting Zhenyu Wang (2018-10-11 10:01:26)
> On 2018.10.11 07:23:11 +0100, Chris Wilson wrote:
> > Quoting Zhenyu Wang (2018-10-11 03:45:07)
> > > On 2018.10.09 14:08:20 +0800, Xiong Zhang wrote:
> > > > The guest couldn't boot up under GVT-g environment as the following call
> > > > trace exists:
> > > > [ 272.504762] BUG: unable to handle kernel NULL pointer dereference at
> > > > 0100
> > > > [ 272.504834] Call Trace:
> > > > [ 272.504852] execlists_context_pin+0x2b2/0x520 [i915]
> > > > [ 272.504869] intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
> > > > [ 272.504887] intel_vgpu_create_workload+0x3e2/0x570 [i915]
> > > > [ 272.504901] intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
> > > > [ 272.504916] elsp_mmio_write+0xc7/0x130 [i915]
> > > > [ 272.504930] intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
> > > > [ 272.504944] intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
> > > > [ 272.504947] intel_vgpu_rw+0x22d/0x270 [kvmgt]
> > > > [ 272.504949] intel_vgpu_write+0x164/0x1f0 [kvmgt]
> > > >
> > > > GVT GEM context is created by i915_gem_context_create_gvt() which
> > > > doesn't
> > > > allocate ppgtt. So GVT GEM context structure doesn't have a valid
> > > > i915_hw_ppgtt.
> > > >
> > > > GVT maintain a shadow ppgtt for each guest ppgtt, and attach this shadow
> > > > ppgtt to gpu when the corresponding guest ppgtt will be scheduled onto
> > > > gpu.
> > > > The structure of shadow ppgtt is different from i915_hw_ppgtt, a lot of
> > > > gvt
> > > > refactor work should be done in order to use i915_hw_ppgtt structure.
> > > > So let's fix the regression first.
> > > >
> > > > Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt
> > > > for execlists")
> > > >
> > > > Signed-off-by: Xiong Zhang
> > > > ---
> > >
> > > Chris, any comment? Without this, current gvt breaks on drm tip with
> > > kernel oops.
> > > Could we fix the regression first then check gvt ctx stub ppgtt handling
> > > later?
> > > Which would require more change on gvt side, not sure if need any more
> > > helper from
> > > i915 ppgtt code with a clean fix..
> >
> > We both thought this wasn't the approach we wanted to take. My position
> > is that this leaves the registers ostensibly programmed to garbage.
>
> yeah, I agree that's not ideal, my point is that would bring more changes e.g
> gvt ctx create function need to be changed accordingly, etc. and I'm
> disappointed why CI didn't catch this in first place, as Terrence has
> contributed GVT guest boot test in igt, we need to add that for list patch
> checking!
>
> Current gvt nightly test is using this one to kick, we'll see if a quick
> mitigation can be made.
Easiest is just to allocate the ctx->ppgtt. We waste a few pages, once.
Later on we can fine tune the integration.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
On Thu, Oct 11, 2018 at 12:11:23PM +0300, Petri Latvala wrote:
> On Thu, Oct 11, 2018 at 11:01:48AM +0200, Daniel Vetter wrote:
> > On Wed, Oct 10, 2018 at 05:20:59PM -0700, Deepak Rawat wrote:
> > > Add DRIVER_VMWGFX to represent vmwgfx device for running igt tests.
> > >
> > > v2: Don't remove second virtio_gpu
> > >
> > > Signed-off-by: Deepak Rawat
> > > ---
> > > lib/drmtest.c | 8
> > > lib/drmtest.h | 3 +++
> > > 2 files changed, 11 insertions(+)
> > >
> > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > index fee9d33a..9d013a00 100644
> > > --- a/lib/drmtest.c
> > > +++ b/lib/drmtest.c
> > > @@ -105,6 +105,11 @@ bool is_i915_device(int fd)
> > > return __is_device(fd, "i915");
> > > }
> > >
> > > +bool is_vmwgfx_device(int fd)
> > > +{
> > > + return __is_device(fd, "vmwg");
> > > +}
> > > +
> > > static bool has_known_intel_chipset(int fd)
> > > {
> > > struct drm_i915_getparam gp;
> > > @@ -206,6 +211,7 @@ static const struct module {
> > > { DRIVER_VGEM, "vgem" },
> > > { DRIVER_VIRTIO, "virtio-gpu" },
> > > { DRIVER_VIRTIO, "virtio_gpu" },
> > > + { DRIVER_VMWGFX, "vmwgfx" },
> > > {}
> > > };
> > >
> > > @@ -348,6 +354,8 @@ static const char *chipset_to_str(int chipset)
> > > return "virtio";
> > > case DRIVER_AMDGPU:
> > > return "amdgpu";
> > > + case DRIVER_VMWGFX:
> > > + return "vmwgfx";
> > > case DRIVER_ANY:
> > > return "any";
> > > default:
> > > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > > index 949865ee..0213fb51 100644
> > > --- a/lib/drmtest.h
> > > +++ b/lib/drmtest.h
> > > @@ -43,6 +43,7 @@
> > > #define DRIVER_VGEM (1 << 2)
> > > #define DRIVER_VIRTIO(1 << 3)
> > > #define DRIVER_AMDGPU(1 << 4)
> > > +#define DRIVER_VMWGFX(1 << 5)
> >
> > This seems not needed? For pure generic kms tests I think it'd be great if
> > we don't have to sprinkle driver-specific checks all over. Which you seem
> > to achive in your series here.
> >
> > So not clear why this here is needed?
>
>
> Loading the .ko needs the name in this array:
>
> > > @@ -206,6 +211,7 @@ static const struct module {
> > > { DRIVER_VGEM, "vgem" },
> > > { DRIVER_VIRTIO, "virtio-gpu" },
> > > { DRIVER_VIRTIO, "virtio_gpu" },
> > > + { DRIVER_VMWGFX, "vmwgfx" },
I guess I don't quite understand why we do that then. Adding driver flags
for every kms driver under the sun isn't a maintainable thing going
forward. And there's definitely people using igt who don't have their
special flag+module autoloader.
vgem and vkms needs it, but that's about it. Everything else sounds like
papering over CI infrastructure mishaps to me ...
-Daniel
>
>
>
> --
> Petri Latvala
>
>
>
>
> > -Daniel
> >
> > > /*
> > > * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> > > * with vgem as well as a supported driver, you can end up with a
> > > @@ -80,6 +81,8 @@ void igt_require_intel(int fd);
> > >
> > > bool is_i915_device(int fd);
> > >
> > > +bool is_vmwgfx_device(int fd);
> > > +
> > > /**
> > > * do_or_die:
> > > * @x: command
> > > --
> > > 2.17.1
> > >
> > > ___
> > > igt-dev mailing list
> > > igt-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make 48bit full ppgtt configuration generic (v7)
Quoting Bob Paauwe (2018-10-08 19:14:06) > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 30191523c309..54a44270d350 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2602,7 +2602,7 @@ intel_info(const struct drm_i915_private *dev_priv) > (INTEL_PPGTT(dev_priv) != INTEL_PPGTT_NONE) > #define HAS_FULL_PPGTT(dev_priv) \ > (INTEL_PPGTT(dev_priv) >= INTEL_PPGTT_FULL) > -#define HAS_FULL_48BIT_PPGTT(dev_priv) \ > +#define HAS_4LVL_PPGTT(dev_priv) \ > (INTEL_PPGTT(dev_priv) >= INTEL_PPGTT_FULL_4LVL) Keep going, your job here is to eliminate INTEL_PPGTT_FULL_4LVL. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Remove crtc->config references in vlv_prepare_pll
We already have a perfectly nice pipe_config, use that instead. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3d3eefa6ec65..bb16a9acf117 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7033,8 +7033,8 @@ static void vlv_prepare_pll(struct intel_crtc *crtc, /* Set HBR and RBR LPF coefficients */ if (pipe_config->port_clock == 162000 || - intel_crtc_has_type(crtc->config, INTEL_OUTPUT_ANALOG) || - intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) + intel_crtc_has_type(pipe_config, INTEL_OUTPUT_ANALOG) || + intel_crtc_has_type(pipe_config, INTEL_OUTPUT_HDMI)) vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW10(pipe), 0x009f0003); else @@ -7061,7 +7061,7 @@ static void vlv_prepare_pll(struct intel_crtc *crtc, coreclk = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW7(pipe)); coreclk = (coreclk & 0xff00) | 0x01c0; - if (intel_crtc_has_dp_encoder(crtc->config)) + if (intel_crtc_has_dp_encoder(pipe_config)) coreclk |= 0x0100; vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW7(pipe), coreclk); -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Always read out M2_N2 in intel_cpu_transcoder_get_m_n
has_drrs is a flag we can't read out. We set it when seamless DRRS is
enabled in pipe_config, so intel_dump_pipe_config() and
intel_pipe_config_compare() will continue to do the right thing when
has_drrs is set on the real state.
This removes one more dereference of crtc->config.
While at it, fixup the comment and also read out M2_N2 for CHV, since
we program it in the set_m_n function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bb16a9acf117..7812fab31646 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6893,8 +6893,8 @@ static void intel_cpu_transcoder_set_m_n(const struct
intel_crtc_state *crtc_sta
I915_WRITE(PIPE_LINK_M1(transcoder), m_n->link_m);
I915_WRITE(PIPE_LINK_N1(transcoder), m_n->link_n);
/* M2_N2 registers to be set only for gen < 8 (M2_N2 available
-* for gen < 8) and if DRRS is supported (to make sure the
-* registers are not unnecessarily accessed).
+* for gen < 8 and CHV) and if DRRS is supported (to make sure
+* the registers are not unnecessarily accessed).
*/
if (m2_n2 && (IS_CHERRYVIEW(dev_priv) ||
INTEL_GEN(dev_priv) < 8) && crtc_state->has_drrs) {
@@ -8747,11 +8747,10 @@ static void intel_cpu_transcoder_get_m_n(struct
intel_crtc *crtc,
m_n->tu = ((I915_READ(PIPE_DATA_M1(transcoder))
& TU_SIZE_MASK) >> TU_SIZE_SHIFT) + 1;
/* Read M2_N2 registers only for gen < 8 (M2_N2 available for
-* gen < 8) and if DRRS is supported (to make sure the
-* registers are not unnecessarily read).
+* gen < 8 and CHV).
*/
- if (m2_n2 && INTEL_GEN(dev_priv) < 8 &&
- crtc->config->has_drrs) {
+ if (m2_n2 && (INTEL_GEN(dev_priv) < 8 ||
+ IS_CHERRYVIEW(dev_priv))) {
m2_n2->link_m = I915_READ(PIPE_LINK_M2(transcoder));
m2_n2->link_n = I915_READ(PIPE_LINK_N2(transcoder));
m2_n2->gmch_m = I915_READ(PIPE_DATA_M2(transcoder))
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: Remove crtc->config dereferences in intel_sanitize_crtc
We know the crtc is idle because we're at the beginning of sanitization,
so just dereference crtc->state instead.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eaf522ef2927..19d7714df021 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15565,7 +15565,8 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+ struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
/* Clear any frame start delays used for debugging left by the BIOS */
if (crtc->active && !transcoder_is_dsi(cpu_transcoder)) {
@@ -15575,7 +15576,7 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
}
- if (crtc->active) {
+ if (crtc_state->base.active) {
struct intel_plane *plane;
/* Disable everything but the primary plane */
@@ -15591,10 +15592,10 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
/* Adjust the state of the output pipe according to whether we
* have active connectors/encoders. */
- if (crtc->active && !intel_crtc_has_encoders(crtc))
+ if (crtc_state->base.active && !intel_crtc_has_encoders(crtc))
intel_crtc_disable_noatomic(&crtc->base, ctx);
- if (crtc->active || HAS_GMCH_DISPLAY(dev_priv)) {
+ if (crtc_state->base.active || HAS_GMCH_DISPLAY(dev_priv)) {
/*
* We start out with underrun reporting disabled to avoid races.
* For correct bookkeeping mark this on active crtcs.
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/10] drm/i915: Pass crtc_state to ivybridge_update_fdi_bc_bifurcation
We have to look at crtc_state, so pass that instead.
Also cleanup the use of dev vs dev_priv, we really want to pass along
dev_priv.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad1694c4d947..ad2c207d18bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4633,9 +4633,8 @@ static void ironlake_pch_transcoder_set_timings(const
struct intel_crtc_state *c
I915_READ(VSYNCSHIFT(cpu_transcoder)));
}
-static void cpt_set_fdi_bc_bifurcation(struct drm_device *dev, bool enable)
+static void cpt_set_fdi_bc_bifurcation(struct drm_i915_private *dev_priv, bool
enable)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
uint32_t temp;
temp = I915_READ(SOUTH_CHICKEN1);
@@ -4654,22 +4653,23 @@ static void cpt_set_fdi_bc_bifurcation(struct
drm_device *dev, bool enable)
POSTING_READ(SOUTH_CHICKEN1);
}
-static void ivybridge_update_fdi_bc_bifurcation(struct intel_crtc *intel_crtc)
+static void ivybridge_update_fdi_bc_bifurcation(const struct intel_crtc_state
*crtc_state)
{
- struct drm_device *dev = intel_crtc->base.dev;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- switch (intel_crtc->pipe) {
+ switch (crtc->pipe) {
case PIPE_A:
break;
case PIPE_B:
- if (intel_crtc->config->fdi_lanes > 2)
- cpt_set_fdi_bc_bifurcation(dev, false);
+ if (crtc_state->fdi_lanes > 2)
+ cpt_set_fdi_bc_bifurcation(dev_priv, false);
else
- cpt_set_fdi_bc_bifurcation(dev, true);
+ cpt_set_fdi_bc_bifurcation(dev_priv, true);
break;
case PIPE_C:
- cpt_set_fdi_bc_bifurcation(dev, true);
+ cpt_set_fdi_bc_bifurcation(dev_priv, true);
break;
default:
@@ -4726,7 +4726,7 @@ static void ironlake_pch_enable(const struct
intel_atomic_state *state,
assert_pch_transcoder_disabled(dev_priv, pipe);
if (IS_IVYBRIDGE(dev_priv))
- ivybridge_update_fdi_bc_bifurcation(crtc);
+ ivybridge_update_fdi_bc_bifurcation(crtc_state);
/* Write the TU size bits before fdi link training, so that error
* detection works. */
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/10] drm/i915: Remove low hanging crtc->config fruit, part 2.
More users of crtc->config are converted to using the correct crtc_state. Maarten Lankhorst (10): drm/i915: Remove crtc->config dereference from drrs_ctl drm/i915: Make intel_dp_set_m_n take crtc_state drm/i915: Remove crtc->config references in vlv_prepare_pll drm/i915: Always read out M2_N2 in intel_cpu_transcoder_get_m_n drm/i915: Pass crtc_state to update_scanline_offset drm/i915: Remove crtc->config dereferences in intel_sanitize_crtc drm/i915: Remove crtc->config dereferences in intel_modeset_setup_hw_state drm/i915: Pass crtc_state to lpt_program_iclkip drm/i915: Pass crtc_state to ivybridge_update_fdi_bc_bifurcation drm/i915: Remove crtc->active from crtc_enable callbacks drivers/gpu/drm/i915/i915_debugfs.c | 54 +++-- drivers/gpu/drm/i915/intel_display.c | 157 --- drivers/gpu/drm/i915/intel_dp.c | 4 +- drivers/gpu/drm/i915/intel_drv.h | 3 +- 4 files changed, 118 insertions(+), 100 deletions(-) -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Make intel_dp_set_m_n take crtc_state
Another user of crtc->config gone. The functions it calls also
needed crtc->config, so convert those as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 61 ++--
drivers/gpu/drm/i915/intel_dp.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
3 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c3fd37a9fd49..3d3eefa6ec65 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -143,9 +143,9 @@ static int intel_framebuffer_init(struct intel_framebuffer
*ifb,
struct drm_mode_fb_cmd2 *mode_cmd);
static void intel_set_pipe_timings(const struct intel_crtc_state *crtc_state);
static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state);
-static void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
-struct intel_link_m_n *m_n,
-struct intel_link_m_n *m2_n2);
+static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state
*crtc_state,
+const struct intel_link_m_n *m_n,
+const struct intel_link_m_n *m2_n2);
static void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state);
static void ironlake_set_pipeconf(const struct intel_crtc_state *crtc_state);
static void haswell_set_pipeconf(const struct intel_crtc_state *crtc_state);
@@ -5604,14 +5604,14 @@ static void ironlake_crtc_enable(struct
intel_crtc_state *pipe_config,
intel_prepare_shared_dpll(pipe_config);
if (intel_crtc_has_dp_encoder(pipe_config))
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(pipe_config, M1_N1);
intel_set_pipe_timings(pipe_config);
intel_set_pipe_src_size(pipe_config);
if (pipe_config->has_pch_encoder) {
- intel_cpu_transcoder_set_m_n(intel_crtc,
-&pipe_config->fdi_m_n, NULL);
+ intel_cpu_transcoder_set_m_n(pipe_config,
+&pipe_config->fdi_m_n, NULL);
}
ironlake_set_pipeconf(pipe_config);
@@ -5728,7 +5728,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_encoders_pre_enable(crtc, pipe_config, old_state);
if (intel_crtc_has_dp_encoder(pipe_config))
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(pipe_config, M1_N1);
if (!transcoder_is_dsi(cpu_transcoder))
intel_set_pipe_timings(pipe_config);
@@ -5742,8 +5742,8 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
}
if (pipe_config->has_pch_encoder) {
- intel_cpu_transcoder_set_m_n(intel_crtc,
-&pipe_config->fdi_m_n, NULL);
+ intel_cpu_transcoder_set_m_n(pipe_config,
+&pipe_config->fdi_m_n, NULL);
}
if (!transcoder_is_dsi(cpu_transcoder))
@@ -6070,7 +6070,7 @@ static void valleyview_crtc_enable(struct
intel_crtc_state *pipe_config,
return;
if (intel_crtc_has_dp_encoder(pipe_config))
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(pipe_config, M1_N1);
intel_set_pipe_timings(pipe_config);
intel_set_pipe_src_size(pipe_config);
@@ -6140,7 +6140,7 @@ static void i9xx_crtc_enable(struct intel_crtc_state
*pipe_config,
i9xx_set_pll_dividers(pipe_config);
if (intel_crtc_has_dp_encoder(pipe_config))
- intel_dp_set_m_n(intel_crtc, M1_N1);
+ intel_dp_set_m_n(pipe_config, M1_N1);
intel_set_pipe_timings(pipe_config);
intel_set_pipe_src_size(pipe_config);
@@ -6865,12 +6865,12 @@ static void vlv_pllb_recal_opamp(struct
drm_i915_private *dev_priv, enum pipe
vlv_dpio_write(dev_priv, pipe, VLV_REF_DW13, reg_val);
}
-static void intel_pch_transcoder_set_m_n(struct intel_crtc *crtc,
-struct intel_link_m_n *m_n)
+static void intel_pch_transcoder_set_m_n(const struct intel_crtc_state
*crtc_state)
{
- struct drm_device *dev = crtc->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- int pipe = crtc->pipe;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct intel_link_m_n *m_n = &crtc_state->dp_m_n;
+ enum pipe pipe = crtc->pipe;
I915_WRITE(PCH_TRANS_DATA_M1(pipe), TU_SIZE(m_n->tu) | m_n->gmch_m);
I915_WRITE(PCH_TRANS_DATA_N1(pipe), m_n->gmch_n);
@@ -6878,13 +6878,14 @@ static void intel_pch_transcoder_set_m_n(struct
intel_crtc *crtc,
[Intel-gfx] [PATCH 05/10] drm/i915: Pass crtc_state to update_scanline_offset
No need to look at crtc->config when we have crtc_state in the caller.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7812fab31646..eaf522ef2927 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12127,8 +12127,9 @@ intel_modeset_verify_disabled(struct drm_device *dev,
verify_disabled_dpll_state(dev);
}
-static void update_scanline_offset(struct intel_crtc *crtc)
+static void update_scanline_offset(const struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
/*
@@ -12159,7 +12160,7 @@ static void update_scanline_offset(struct intel_crtc
*crtc)
* answer that's slightly in the future.
*/
if (IS_GEN2(dev_priv)) {
- const struct drm_display_mode *adjusted_mode =
&crtc->config->base.adjusted_mode;
+ const struct drm_display_mode *adjusted_mode =
&crtc_state->base.adjusted_mode;
int vtotal;
vtotal = adjusted_mode->crtc_vtotal;
@@ -12168,7 +12169,7 @@ static void update_scanline_offset(struct intel_crtc
*crtc)
crtc->scanline_offset = vtotal - 1;
} else if (HAS_DDI(dev_priv) &&
- intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) {
+ intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
crtc->scanline_offset = 2;
} else
crtc->scanline_offset = 1;
@@ -12522,7 +12523,7 @@ static void intel_update_crtc(struct drm_crtc *crtc,
to_intel_plane(crtc->primary));
if (modeset) {
- update_scanline_offset(intel_crtc);
+ update_scanline_offset(pipe_config);
dev_priv->display.crtc_enable(pipe_config, state);
/* vblanks work again, re-enable pipe CRC. */
@@ -15868,7 +15869,7 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
drm_calc_timestamping_constants(&crtc->base,
&crtc_state->base.adjusted_mode);
- update_scanline_offset(crtc);
+ update_scanline_offset(crtc_state);
}
dev_priv->min_cdclk[crtc->pipe] = min_cdclk;
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Remove crtc->config dereferences in intel_modeset_setup_hw_state
The CRTC is idle at this point, so we can dereference crtc->state safely.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 19d7714df021..cbe70bc4d02d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15934,6 +15934,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *crtc;
+ struct intel_crtc_state *crtc_state;
struct intel_encoder *encoder;
int i;
@@ -15952,7 +15953,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
for_each_intel_crtc(&dev_priv->drm, crtc) {
drm_crtc_vblank_reset(&crtc->base);
- if (crtc->active)
+ if (crtc->base.state->active)
drm_crtc_vblank_on(&crtc->base);
}
@@ -15961,9 +15962,10 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
for_each_intel_encoder(dev, encoder)
intel_sanitize_encoder(encoder);
- for_each_intel_crtc(&dev_priv->drm, crtc) {
+ for_each_intel_crtc(dev, crtc) {
+ crtc_state = to_intel_crtc_state(crtc->base.state);
intel_sanitize_crtc(crtc, ctx);
- intel_dump_pipe_config(crtc, crtc->config,
+ intel_dump_pipe_config(crtc, crtc_state,
"[setup_hw_state]");
}
@@ -15997,7 +15999,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
for_each_intel_crtc(dev, crtc) {
u64 put_domains;
- put_domains = modeset_get_crtc_power_domains(&crtc->base,
crtc->config);
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+ put_domains = modeset_get_crtc_power_domains(&crtc->base,
crtc_state);
if (WARN_ON(put_domains))
modeset_put_power_domains(dev_priv, put_domains);
}
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: Remove crtc->config dereference from drrs_ctl
Wait for idle, and iterate over connectors instead of encoders.
With this information we know crtc->state is the actual state,
and we can enable/disable drrs safely.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 54 ++---
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f42e93b71e67..b04d5ade5a15 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4661,20 +4661,45 @@ static int i915_drrs_ctl_set(void *data, u64 val)
{
struct drm_i915_private *dev_priv = data;
struct drm_device *dev = &dev_priv->drm;
- struct intel_crtc *intel_crtc;
- struct intel_encoder *encoder;
- struct intel_dp *intel_dp;
+ struct intel_crtc *crtc;
if (INTEL_GEN(dev_priv) < 7)
return -ENODEV;
- drm_modeset_lock_all(dev);
- for_each_intel_crtc(dev, intel_crtc) {
- if (!intel_crtc->base.state->active ||
- !intel_crtc->config->has_drrs)
- continue;
+ for_each_intel_crtc(dev, crtc) {
+ struct drm_connector_list_iter conn_iter;
+ struct intel_crtc_state *crtc_state;
+ struct drm_connector *connector;
+ struct drm_crtc_commit *commit;
+ int ret;
+
+ ret = drm_modeset_lock_single_interruptible(&crtc->base.mutex);
+ if (ret)
+ return ret;
+
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
+ if (!crtc_state->base.active ||
+ !crtc_state->has_drrs)
+ goto out;
- for_each_encoder_on_crtc(dev, &intel_crtc->base, encoder) {
+ commit = crtc_state->base.commit;
+ if (commit) {
+ ret =
wait_for_completion_interruptible(&commit->hw_done);
+ if (ret)
+ goto out;
+ }
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(connector, &conn_iter) {
+ struct intel_encoder *encoder;
+ struct intel_dp *intel_dp;
+
+ if (!(crtc_state->base.connector_mask &
+ drm_connector_mask(connector)))
+ continue;
+
+ encoder = intel_attached_encoder(connector);
if (encoder->type != INTEL_OUTPUT_EDP)
continue;
@@ -4684,13 +4709,18 @@ static int i915_drrs_ctl_set(void *data, u64 val)
intel_dp = enc_to_intel_dp(&encoder->base);
if (val)
intel_edp_drrs_enable(intel_dp,
- intel_crtc->config);
+ crtc_state);
else
intel_edp_drrs_disable(intel_dp,
- intel_crtc->config);
+ crtc_state);
}
+ drm_connector_list_iter_end(&conn_iter);
+
+out:
+ drm_modeset_unlock(&crtc->base.mutex);
+ if (ret)
+ return ret;
}
- drm_modeset_unlock_all(dev);
return 0;
}
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Remove crtc->active from crtc_enable callbacks
Now that most of the driver is atomic, we no longer need to worry
about setting crtc->active right before actually enabling the pipe.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad2c207d18bb..0e4bdd5c337e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5585,9 +5585,6 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
struct intel_atomic_state *old_intel_state =
to_intel_atomic_state(old_state);
- if (WARN_ON(intel_crtc->active))
- return;
-
/*
* Sometimes spurious CPU pipe underruns happen during FDI
* training, at least with VGA+HDMI cloning. Suppress them.
@@ -5617,8 +5614,6 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
ironlake_set_pipeconf(pipe_config);
- intel_crtc->active = true;
-
intel_encoders_pre_enable(crtc, pipe_config, old_state);
if (pipe_config->has_pch_encoder) {
@@ -5715,9 +5710,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
bool psl_clkgate_wa;
u32 pipe_chicken;
- if (WARN_ON(intel_crtc->active))
- return;
-
intel_encoders_pre_pll_enable(crtc, pipe_config, old_state);
if (pipe_config->shared_dpll)
@@ -5754,8 +5746,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_color_set_csc(&pipe_config->base);
- intel_crtc->active = true;
-
/* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
pipe_config->pch_pfit.enabled;
@@ -6067,9 +6057,6 @@ static void valleyview_crtc_enable(struct
intel_crtc_state *pipe_config,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
- if (WARN_ON(intel_crtc->active))
- return;
-
if (intel_crtc_has_dp_encoder(pipe_config))
intel_dp_set_m_n(pipe_config, M1_N1);
@@ -6085,8 +6072,6 @@ static void valleyview_crtc_enable(struct
intel_crtc_state *pipe_config,
intel_color_set_csc(&pipe_config->base);
- intel_crtc->active = true;
-
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
intel_encoders_pre_pll_enable(crtc, pipe_config, old_state);
@@ -6135,9 +6120,6 @@ static void i9xx_crtc_enable(struct intel_crtc_state
*pipe_config,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
- if (WARN_ON(intel_crtc->active))
- return;
-
i9xx_set_pll_dividers(pipe_config);
if (intel_crtc_has_dp_encoder(pipe_config))
@@ -6148,8 +6130,6 @@ static void i9xx_crtc_enable(struct intel_crtc_state
*pipe_config,
i9xx_set_pipeconf(pipe_config);
- intel_crtc->active = true;
-
if (!IS_GEN2(dev_priv))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
@@ -12525,6 +12505,7 @@ static void intel_update_crtc(struct drm_crtc *crtc,
if (modeset) {
update_scanline_offset(pipe_config);
+ intel_crtc->active = true;
dev_priv->display.crtc_enable(pipe_config, state);
/* vblanks work again, re-enable pipe CRC. */
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: Pass crtc_state to lpt_program_iclkip
Instead of derferencing crtc->config, look at crtc_state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cbe70bc4d02d..ad1694c4d947 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4494,10 +4494,11 @@ void lpt_disable_iclkip(struct drm_i915_private
*dev_priv)
}
/* Program iCLKIP clock to the desired frequency */
-static void lpt_program_iclkip(struct intel_crtc *crtc)
+static void lpt_program_iclkip(const struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- int clock = crtc->config->base.adjusted_mode.crtc_clock;
+ int clock = crtc_state->base.adjusted_mode.crtc_clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
@@ -4806,7 +4807,7 @@ static void lpt_pch_enable(const struct
intel_atomic_state *state,
assert_pch_transcoder_disabled(dev_priv, PIPE_A);
- lpt_program_iclkip(crtc);
+ lpt_program_iclkip(crtc_state);
/* Set transcoder timing. */
ironlake_pch_transcoder_set_timings(crtc_state, PIPE_A);
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/perf: do not warn when OA buffer is already allocated
On 10/10/2018 20:24, Matthew Auld wrote: On Wed, 10 Oct 2018 at 19:55, Lionel Landwerlin wrote: If 2 processes race to open the perf stream, it's possible that one of them will see that OA buffer has already been allocated, while a previous process is still finishing to reprogram the hardware (on gen8+). The opening sequence has been reworked a few times and we probably lost track of the order in which things are supposed to happen. Signed-off-by: Lionel Landwerlin Accidental resend, or did the locking actually change recently? Indeed Sorry for that, dropping for good! - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/6] drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()
== Series Details ==
Series: series starting with [v2,1/6] drm/i915/psr: Use intel_psr_exit() in
intel_psr_disable_source()
URL : https://patchwork.freedesktop.org/series/50843/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4967_full -> Patchwork_10420_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10420_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10420_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_10420_full:
=== IGT changes ===
Warnings
igt@perf_pmu@rc6:
shard-kbl: SKIP -> PASS
== Known issues ==
Here are the changes found in Patchwork_10420_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@drv_suspend@fence-restore-tiled2untiled:
shard-skl: NOTRUN -> INCOMPLETE (fdo#104108, fdo#107773)
igt@gem_exec_schedule@pi-ringfull-blt:
shard-skl: NOTRUN -> FAIL (fdo#103158)
igt@gem_ppgtt@blt-vs-render-ctx0:
shard-skl: NOTRUN -> TIMEOUT (fdo#108039)
igt@gem_userptr_blits@readonly-unsync:
shard-skl: NOTRUN -> INCOMPLETE (fdo#108074)
igt@kms_addfb_basic@bo-too-small-due-to-tiling:
shard-snb: NOTRUN -> INCOMPLETE (fdo#105411)
igt@kms_atomic_transition@2x-modeset-transitions-nonblocking-fencing:
shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359)
igt@kms_available_modes_crc@available_mode_test_crc:
shard-apl: PASS -> FAIL (fdo#106641)
igt@kms_busy@extended-modeset-hang-newfb-render-b:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
shard-snb: NOTRUN -> DMESG-WARN (fdo#107956) +2
igt@kms_cursor_crc@cursor-128x128-dpms:
shard-apl: PASS -> FAIL (fdo#103232)
igt@kms_cursor_crc@cursor-64x64-dpms:
shard-glk: PASS -> FAIL (fdo#103232) +1
igt@kms_cursor_legacy@cursora-vs-flipa-toggle:
shard-glk: PASS -> DMESG-WARN (fdo#106538, fdo#105763)
igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled:
shard-skl: PASS -> FAIL (fdo#103184)
igt@kms_flip@flip-vs-expired-vblank-interruptible:
shard-snb: NOTRUN -> DMESG-WARN (fdo#107469)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
shard-apl: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
shard-glk: PASS -> FAIL (fdo#103167) +3
igt@kms_frontbuffer_tracking@fbcpsr-stridechange:
shard-skl: NOTRUN -> FAIL (fdo#105683)
igt@kms_pipe_crc_basic@read-crc-pipe-c:
shard-skl: NOTRUN -> FAIL (fdo#107362) +1
{igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min}:
shard-skl: NOTRUN -> FAIL (fdo#108145) +2
{igt@kms_plane_alpha_blend@pipe-c-coverage-7efc}:
shard-skl: NOTRUN -> FAIL (fdo#108146)
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-apl: PASS -> FAIL (fdo#103166) +2
igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
shard-glk: PASS -> FAIL (fdo#103166) +3
igt@kms_setmode@basic:
shard-apl: PASS -> FAIL (fdo#99912)
shard-kbl: PASS -> FAIL (fdo#99912)
shard-snb: NOTRUN -> FAIL (fdo#99912)
igt@perf_pmu@rc6-runtime-pm:
shard-apl: PASS -> FAIL (fdo#105010)
Possible fixes
igt@kms_busy@extended-pageflip-hang-newfb-render-c:
shard-glk: DMESG-WARN (fdo#107956) -> PASS
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
shard-hsw: DMESG-WARN (fdo#107956) -> PASS
igt@kms_color@pipe-a-ctm-max:
shard-skl: FAIL -> PASS
igt@kms_cursor_crc@cursor-128x128-random:
shard-apl: FAIL (fdo#103232) -> PASS +2
igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
shard-glk: DMESG-WARN (fdo#106538, fdo#105763) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
shard-apl: FAIL (fdo#103167) -> PASS +1
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
shard-glk: FAIL (fdo#103167) -> PASS +3
igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-cpu:
shard-glk: DMESG-FAIL (fdo#106538) -> PASS
igt@kms_frontbuffer_tracking@psr-farfromfence:
shard-skl: FAIL (fdo#103167) -> PASS
{igt@kms_plane_alpha_blend@pipe-a-coverage-7efc}:
shard-skl: FAIL (fdo#108145) -> PASS
{igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max}:
[Intel-gfx] [PATCH] drm/i915/selftests: Disable shrinker across mmap-exhaustion
For mmap-exhaustion, we deliberately put the system under a large amount
of pressure to ensure that we are able to reap mmap-offsets from dead
objects. If background activity does that reaping for us, that defeats
the purpose of the test and in some cases will fail our sanity checks
(because of the fake activity we use to prevent the idle worker).
Fixes: 932cac10c8fb ("drm/i915/selftests: Prevent background reaping of acti
ve objects")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
index 6d3516d5bff9..c3999dd2021e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
@@ -501,6 +501,8 @@ static bool assert_mmap_offset(struct drm_i915_private
*i915,
static void disable_retire_worker(struct drm_i915_private *i915)
{
+ i915_gem_shrinker_unregister(i915);
+
mutex_lock(&i915->drm.struct_mutex);
if (!i915->gt.active_requests++) {
intel_runtime_pm_get(i915);
@@ -613,6 +615,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
else
queue_delayed_work(i915->wq, &i915->gt.idle_work, 0);
mutex_unlock(&i915->drm.struct_mutex);
+ i915_gem_shrinker_register(i915);
return err;
err_obj:
i915_gem_object_put(obj);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove low hanging crtc->config fruit, part 2.
== Series Details ==
Series: drm/i915: Remove low hanging crtc->config fruit, part 2.
URL : https://patchwork.freedesktop.org/series/50856/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4969 -> Patchwork_10423 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10423 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10423, 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/50856/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_10423:
=== IGT changes ===
Possible regressions
igt@debugfs_test@read_all_entries:
fi-hsw-4770r: PASS -> DMESG-WARN +1
== Known issues ==
Here are the changes found in Patchwork_10423 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_exec_suspend@basic-s4-devices:
fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128, fdo#107139)
igt@kms_frontbuffer_tracking@basic:
{fi-icl-u2}:SKIP -> FAIL (fdo#103167)
fi-glk-j4005: PASS -> FAIL (fdo#103167)
Possible fixes
igt@gem_exec_suspend@basic-s3:
fi-cfl-8109u: INCOMPLETE (fdo#107187, fdo#108126) -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: WARN -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
fdo#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126
== Participating hosts (44 -> 41) ==
Missing(3): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
== Build changes ==
* Linux: CI_DRM_4969 -> Patchwork_10423
CI_DRM_4969: 1121d2889e57dedacc0885deaaa9de614832e62f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10423: 518326da7b388dc590bb100447a53ebd36766cdc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
518326da7b38 drm/i915: Remove crtc->active from crtc_enable callbacks
a294d3a692c3 drm/i915: Pass crtc_state to ivybridge_update_fdi_bc_bifurcation
8847505f3a0d drm/i915: Pass crtc_state to lpt_program_iclkip
dda83f80db38 drm/i915: Remove crtc->config dereferences in
intel_modeset_setup_hw_state
5ec681b34f6c drm/i915: Remove crtc->config dereferences in intel_sanitize_crtc
1b3d07b4919a drm/i915: Pass crtc_state to update_scanline_offset
e8010cbd4f8e drm/i915: Always read out M2_N2 in intel_cpu_transcoder_get_m_n
ebe23015acff drm/i915: Remove crtc->config references in vlv_prepare_pll
a508491f6269 drm/i915: Make intel_dp_set_m_n take crtc_state
a739110adcb3 drm/i915: Remove crtc->config dereference from drrs_ctl
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10423/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 drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev2)
== Series Details == Series: drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev2) URL : https://patchwork.freedesktop.org/series/34969/ State : failure == Summary == Applying: drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_gem_gtt.c M drivers/gpu/drm/i915/i915_gpu_error.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_gpu_error.c Auto-merging drivers/gpu/drm/i915/i915_gem_gtt.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_gtt.c Auto-merging drivers/gpu/drm/i915/i915_drv.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.h error: Failed to merge in the changes. Patch failed at 0001 drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7429/ ___ 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/selftests: Disable shrinker across mmap-exhaustion
== Series Details ==
Series: drm/i915/selftests: Disable shrinker across mmap-exhaustion
URL : https://patchwork.freedesktop.org/series/50857/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4969 -> Patchwork_10424 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/50857/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10424 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614)
{fi-icl-u2}:SKIP -> FAIL (fdo#103167)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362)
Possible fixes
igt@gem_exec_suspend@basic-s3:
fi-cfl-8109u: INCOMPLETE (fdo#107187, fdo#108126) -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: WARN (fdo#102672) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126
== Participating hosts (44 -> 40) ==
Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-pnv-d510
== Build changes ==
* Linux: CI_DRM_4969 -> Patchwork_10424
CI_DRM_4969: 1121d2889e57dedacc0885deaaa9de614832e62f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10424: dd80977e7f7e8052480b03cf4a075acb70d2053a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dd80977e7f7e drm/i915/selftests: Disable shrinker across mmap-exhaustion
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10424/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Add CRTC background color property
On Wed, Oct 10, 2018 at 04:50:50PM -0700, Matt Roper wrote:
> 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.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: wei.c...@intel.com
> Cc: harish.krupo@intel.com
> 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_mode_config.c | 6 ++
> include/drm/drm_crtc.h| 17 +
> include/drm/drm_mode_config.h | 5 +
> include/uapi/drm/drm_mode.h | 26 ++
> 6 files changed, 60 insertions(+)
>
> 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 d5b7f315098c..399f0ead5370 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->background_color = 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->background_color;
> 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_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index ee80788f2c40..75e376755176 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -352,6 +352,12 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.modifiers_property = prop;
>
> + prop = drm_property_create_range(dev, 0, "BACKGROUND_COLOR",
> + 0, GENMASK_ULL(63, 0));
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.bgcolor_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b21437bc95bf..ddfdad9ccecb 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -168,6 +168,11 @@ struct drm_crtc_state {
>* drivers to steer the atomic commit control flow.
>*/
> bool color_mgmt_changed : 1;
> + /**
> + * @bgcolor_changed: Background color value has changed. Used by
> + * drivers to steer the atomic commit control flow.
> + */
> + bool bgcolor_changed : 1;
>
> /**
>* @no_vblank:
> @@ -274,6 +279,18 @@ struct drm_crtc_state {
>*/
> struct drm_property_blob *gamma_lut;
>
> + /**
> + * @background_color:
> + *
> + * RGB value representing the pipe's background color. The background
> + * color (aka "canvas color") of a pipe is the color that will be used
> + * for pixels not covered by a plane, or covered by transparent pixels
> + * of a plane. The value here should be built via drm_rgba();
> + * individual color components can be extracted with desired precision
> + * via the DRM_RGBA_*() macros.
> + */
> + u64 background_color;
> +
> /**
>* @target_vblank:
>*
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen9+: Add support for pipe background color
On Wed, Oct 10, 2018 at 04:50:51PM -0700, Matt Roper wrote:
> 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.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: wei.c...@intel.com
> Cc: harish.krupo@intel.com
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 9 +
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_display.c | 34 ++
> 3 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 4565eda29c87..cc423f7f3e62 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.background_color;
> +
> + 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/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 20785417953d..988183870f6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5661,6 +5661,12 @@ enum {
> #define PIPEMISC_DITHER_TYPE_SP(0 << 2)
> #define PIPEMISC(pipe) _MMIO_PIPE2(pipe, _PIPE_MISC_A)
>
> +/* Skylake+ pipe bottom (background) color */
> +#define _PIPE_BOTTOM_COLOR_A 0x70034
> +#define PIPE_BOTTOM_GAMMA_ENABLE (1 << 31)
> +#define PIPE_BOTTOM_CSC_ENABLE (1 << 30)
> +#define PIPE_BOTTOM_COLOR(pipe) _MMIO_PIPE2(pipe,
> _PIPE_BOTTOM_COLOR_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 a145efba9157..2ee402a98e70 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3853,6 +3853,28 @@ 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.background_color;
> + uint32_t hwval;
Just 'val' or 'tmp' would be more consistent with existing code.
> +
> + /* Hardware is programmed with 10 bits of precision */
> + hwval = 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.
> + */
> + hwval |= PIPE_BOTTOM_CSC_ENABLE;
> + hwval |= PIPE_BOTTOM_GAMMA_ENABLE;
Maybe we want these as a separate bugfix up front?
> +
> + I915_WRITE_FW(PIPE_BOTTOM_COLOR(crtc->pipe), hwval);
> +}
> +
> static void intel_update_pipe_config(const struct intel_crtc_state
> *old_crtc_state,
>const struct intel_crtc_state
> *new_crtc_state)
> {
> @@ -3887,6 +3909,9 @@ 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);
> }
> +
> + if (new_crtc_state->base.bgcolor_changed)
> + skl_update_background_color(new_crtc_state);
> }
>
> static void intel_fdi_normal_train(struct intel_crtc *crtc)
> @@ -10791,6 +10816,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);
> @@ -13831,6 +13859,7 @@ static void intel_crtc_init_scalers(struct intel_crtc
> *crtc,
>
> static int intel_crtc_init(str
[Intel-gfx] [PATCH] drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture
Since capturing the error state requires fiddling around with the GGTT
to read arbitrary buffers and is itself run under stop_machine(), it
deadlocks the machine (effectively a hard hang) when run in conjunction
with Broxton's VTd workaround to serialize GGTT access.
v2: Store the ERR_PTR in first_error so that the error can be reported
to the user via sysfs.
Fixes: 0ef34ad6222a ("drm/i915: Serialize GTT/Aperture accesses on BXT")
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: John Harrison
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 15 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 8 +++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 29ca9007a704..47b003daa6f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3339,6 +3339,9 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.insert_page= bxt_vtd_ggtt_insert_page__BKL;
if (ggtt->vm.clear_range != nop_clear_range)
ggtt->vm.clear_range = bxt_vtd_ggtt_clear_range__BKL;
+
+ /* Prevent recursively calling stop_machine() and deadlocks. */
+ i915_disable_error_state(dev_priv, -ENODEV);
}
ggtt->invalidate = gen6_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index c8d8f79688a8..f5b9914e9c6d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -648,6 +648,9 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf
*m,
return 0;
}
+ if (IS_ERR(error))
+ return PTR_ERR(error);
+
if (*error->error_msg)
err_printf(m, "%s\n", error->error_msg);
err_printf(m, "Kernel: " UTS_RELEASE "\n");
@@ -1867,6 +1870,7 @@ void i915_capture_error_state(struct drm_i915_private
*i915,
error = i915_capture_gpu_state(i915);
if (!error) {
DRM_DEBUG_DRIVER("out of memory, not capturing error state\n");
+ i915_disable_error_state(dev_priv, -ENOMEM);
return;
}
@@ -1922,5 +1926,14 @@ void i915_reset_error_state(struct drm_i915_private
*i915)
i915->gpu_error.first_error = NULL;
spin_unlock_irq(&i915->gpu_error.lock);
- i915_gpu_state_put(error);
+ if (!IS_ERR(error))
+ i915_gpu_state_put(error);
+}
+
+void i915_disable_error_state(struct drm_i915_private *i915, int err)
+{
+ spin_lock_irq(&i915->gpu_error.lock);
+ if (!i915->gpu_error.first_error)
+ i915->gpu_error.first_error = ERR_PTR(err);
+ spin_unlock_irq(&i915->gpu_error.lock);
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 8710fb18ed74..3ec89a504de5 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -343,6 +343,7 @@ static inline void i915_gpu_state_put(struct i915_gpu_state
*gpu)
struct i915_gpu_state *i915_first_error_state(struct drm_i915_private *i915);
void i915_reset_error_state(struct drm_i915_private *i915);
+void i915_disable_error_state(struct drm_i915_private *i915, int err);
#else
@@ -355,13 +356,18 @@ static inline void i915_capture_error_state(struct
drm_i915_private *dev_priv,
static inline struct i915_gpu_state *
i915_first_error_state(struct drm_i915_private *i915)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
static inline void i915_reset_error_state(struct drm_i915_private *i915)
{
}
+static inline void i915_disable_error_state(struct drm_i915_private *i915,
+ int err)
+{
+}
+
#endif /* IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR) */
#endif /* _I915_GPU_ERROR_H_ */
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Remove crtc->config references in vlv_prepare_pll
On Thu, Oct 11, 2018 at 12:04:50PM +0200, Maarten Lankhorst wrote: > We already have a perfectly nice pipe_config, use that instead. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 3d3eefa6ec65..bb16a9acf117 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -7033,8 +7033,8 @@ static void vlv_prepare_pll(struct intel_crtc *crtc, > > /* Set HBR and RBR LPF coefficients */ > if (pipe_config->port_clock == 162000 || > - intel_crtc_has_type(crtc->config, INTEL_OUTPUT_ANALOG) || > - intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) > + intel_crtc_has_type(pipe_config, INTEL_OUTPUT_ANALOG) || > + intel_crtc_has_type(pipe_config, INTEL_OUTPUT_HDMI)) > vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW10(pipe), >0x009f0003); > else > @@ -7061,7 +7061,7 @@ static void vlv_prepare_pll(struct intel_crtc *crtc, > > coreclk = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW7(pipe)); > coreclk = (coreclk & 0xff00) | 0x01c0; > - if (intel_crtc_has_dp_encoder(crtc->config)) > + if (intel_crtc_has_dp_encoder(pipe_config)) > coreclk |= 0x0100; > vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW7(pipe), coreclk); > > -- > 2.19.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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: failure for drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev3)
== Series Details == Series: drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev3) URL : https://patchwork.freedesktop.org/series/34969/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_gpu_error.o drivers/gpu/drm/i915/i915_gpu_error.c: In function ‘i915_capture_error_state’: drivers/gpu/drm/i915/i915_gpu_error.c:1873:28: error: ‘dev_priv’ undeclared (first use in this function); did you mean ‘dev_crit’? i915_disable_error_state(dev_priv, -ENOMEM); ^~~~ dev_crit drivers/gpu/drm/i915/i915_gpu_error.c:1873:28: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:305: recipe for target 'drivers/gpu/drm/i915/i915_gpu_error.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gpu_error.o] Error 1 scripts/Makefile.build:546: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:546: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:546: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1050: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Make intel_dp_set_m_n take crtc_state
On Thu, Oct 11, 2018 at 12:04:49PM +0200, Maarten Lankhorst wrote:
> Another user of crtc->config gone. The functions it calls also
> needed crtc->config, so convert those as well.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 61 ++--
> drivers/gpu/drm/i915/intel_dp.c | 4 +-
> drivers/gpu/drm/i915/intel_drv.h | 3 +-
> 3 files changed, 35 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c3fd37a9fd49..3d3eefa6ec65 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -143,9 +143,9 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *ifb,
> struct drm_mode_fb_cmd2 *mode_cmd);
> static void intel_set_pipe_timings(const struct intel_crtc_state
> *crtc_state);
> static void intel_set_pipe_src_size(const struct intel_crtc_state
> *crtc_state);
> -static void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
> - struct intel_link_m_n *m_n,
> - struct intel_link_m_n *m2_n2);
> +static void intel_cpu_transcoder_set_m_n(const struct intel_crtc_state
> *crtc_state,
> + const struct intel_link_m_n *m_n,
> + const struct intel_link_m_n *m2_n2);
> static void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state);
> static void ironlake_set_pipeconf(const struct intel_crtc_state *crtc_state);
> static void haswell_set_pipeconf(const struct intel_crtc_state *crtc_state);
> @@ -5604,14 +5604,14 @@ static void ironlake_crtc_enable(struct
> intel_crtc_state *pipe_config,
> intel_prepare_shared_dpll(pipe_config);
>
> if (intel_crtc_has_dp_encoder(pipe_config))
> - intel_dp_set_m_n(intel_crtc, M1_N1);
> + intel_dp_set_m_n(pipe_config, M1_N1);
>
> intel_set_pipe_timings(pipe_config);
> intel_set_pipe_src_size(pipe_config);
>
> if (pipe_config->has_pch_encoder) {
> - intel_cpu_transcoder_set_m_n(intel_crtc,
> - &pipe_config->fdi_m_n, NULL);
> + intel_cpu_transcoder_set_m_n(pipe_config,
> + &pipe_config->fdi_m_n, NULL);
> }
>
> ironlake_set_pipeconf(pipe_config);
> @@ -5728,7 +5728,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> intel_encoders_pre_enable(crtc, pipe_config, old_state);
>
> if (intel_crtc_has_dp_encoder(pipe_config))
> - intel_dp_set_m_n(intel_crtc, M1_N1);
> + intel_dp_set_m_n(pipe_config, M1_N1);
>
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_set_pipe_timings(pipe_config);
> @@ -5742,8 +5742,8 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> }
>
> if (pipe_config->has_pch_encoder) {
> - intel_cpu_transcoder_set_m_n(intel_crtc,
> - &pipe_config->fdi_m_n, NULL);
> + intel_cpu_transcoder_set_m_n(pipe_config,
> + &pipe_config->fdi_m_n, NULL);
> }
>
> if (!transcoder_is_dsi(cpu_transcoder))
> @@ -6070,7 +6070,7 @@ static void valleyview_crtc_enable(struct
> intel_crtc_state *pipe_config,
> return;
>
> if (intel_crtc_has_dp_encoder(pipe_config))
> - intel_dp_set_m_n(intel_crtc, M1_N1);
> + intel_dp_set_m_n(pipe_config, M1_N1);
>
> intel_set_pipe_timings(pipe_config);
> intel_set_pipe_src_size(pipe_config);
> @@ -6140,7 +6140,7 @@ static void i9xx_crtc_enable(struct intel_crtc_state
> *pipe_config,
> i9xx_set_pll_dividers(pipe_config);
>
> if (intel_crtc_has_dp_encoder(pipe_config))
> - intel_dp_set_m_n(intel_crtc, M1_N1);
> + intel_dp_set_m_n(pipe_config, M1_N1);
>
> intel_set_pipe_timings(pipe_config);
> intel_set_pipe_src_size(pipe_config);
> @@ -6865,12 +6865,12 @@ static void vlv_pllb_recal_opamp(struct
> drm_i915_private *dev_priv, enum pipe
> vlv_dpio_write(dev_priv, pipe, VLV_REF_DW13, reg_val);
> }
>
> -static void intel_pch_transcoder_set_m_n(struct intel_crtc *crtc,
> - struct intel_link_m_n *m_n)
> +static void intel_pch_transcoder_set_m_n(const struct intel_crtc_state
> *crtc_state)
I'd probably still pass the m_n struct in explicity here as there's
nothing in the function name that says "this is for dp only".
Apart from that lgtm
Reviewed-by: Ville Syrjälä
> {
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - int pipe = crtc->pipe;
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *de
[Intel-gfx] [PATCH] drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture
Since capturing the error state requires fiddling around with the GGTT
to read arbitrary buffers and is itself run under stop_machine(), it
deadlocks the machine (effectively a hard hang) when run in conjunction
with Broxton's VTd workaround to serialize GGTT access.
v2: Store the ERR_PTR in first_error so that the error can be reported
to the user via sysfs.
Fixes: 0ef34ad6222a ("drm/i915: Serialize GTT/Aperture accesses on BXT")
Signed-off-by: Chris Wilson
Cc: Jon Bloomfield
Cc: John Harrison
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 15 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 8 +++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 29ca9007a704..47b003daa6f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3339,6 +3339,9 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.insert_page= bxt_vtd_ggtt_insert_page__BKL;
if (ggtt->vm.clear_range != nop_clear_range)
ggtt->vm.clear_range = bxt_vtd_ggtt_clear_range__BKL;
+
+ /* Prevent recursively calling stop_machine() and deadlocks. */
+ i915_disable_error_state(dev_priv, -ENODEV);
}
ggtt->invalidate = gen6_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index c8d8f79688a8..21b5c8765015 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -648,6 +648,9 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf
*m,
return 0;
}
+ if (IS_ERR(error))
+ return PTR_ERR(error);
+
if (*error->error_msg)
err_printf(m, "%s\n", error->error_msg);
err_printf(m, "Kernel: " UTS_RELEASE "\n");
@@ -1867,6 +1870,7 @@ void i915_capture_error_state(struct drm_i915_private
*i915,
error = i915_capture_gpu_state(i915);
if (!error) {
DRM_DEBUG_DRIVER("out of memory, not capturing error state\n");
+ i915_disable_error_state(i915, -ENOMEM);
return;
}
@@ -1922,5 +1926,14 @@ void i915_reset_error_state(struct drm_i915_private
*i915)
i915->gpu_error.first_error = NULL;
spin_unlock_irq(&i915->gpu_error.lock);
- i915_gpu_state_put(error);
+ if (!IS_ERR(error))
+ i915_gpu_state_put(error);
+}
+
+void i915_disable_error_state(struct drm_i915_private *i915, int err)
+{
+ spin_lock_irq(&i915->gpu_error.lock);
+ if (!i915->gpu_error.first_error)
+ i915->gpu_error.first_error = ERR_PTR(err);
+ spin_unlock_irq(&i915->gpu_error.lock);
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 8710fb18ed74..3ec89a504de5 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -343,6 +343,7 @@ static inline void i915_gpu_state_put(struct i915_gpu_state
*gpu)
struct i915_gpu_state *i915_first_error_state(struct drm_i915_private *i915);
void i915_reset_error_state(struct drm_i915_private *i915);
+void i915_disable_error_state(struct drm_i915_private *i915, int err);
#else
@@ -355,13 +356,18 @@ static inline void i915_capture_error_state(struct
drm_i915_private *dev_priv,
static inline struct i915_gpu_state *
i915_first_error_state(struct drm_i915_private *i915)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
static inline void i915_reset_error_state(struct drm_i915_private *i915)
{
}
+static inline void i915_disable_error_state(struct drm_i915_private *i915,
+ int err)
+{
+}
+
#endif /* IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR) */
#endif /* _I915_GPU_ERROR_H_ */
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm/i915: Always read out M2_N2 in intel_cpu_transcoder_get_m_n
On Thu, Oct 11, 2018 at 12:04:51PM +0200, Maarten Lankhorst wrote:
> has_drrs is a flag we can't read out. We set it when seamless DRRS is
> enabled in pipe_config, so intel_dump_pipe_config() and
> intel_pipe_config_compare() will continue to do the right thing when
> has_drrs is set on the real state.
>
> This removes one more dereference of crtc->config.
> While at it, fixup the comment and also read out M2_N2 for CHV, since
> we program it in the set_m_n function.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bb16a9acf117..7812fab31646 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6893,8 +6893,8 @@ static void intel_cpu_transcoder_set_m_n(const struct
> intel_crtc_state *crtc_sta
> I915_WRITE(PIPE_LINK_M1(transcoder), m_n->link_m);
> I915_WRITE(PIPE_LINK_N1(transcoder), m_n->link_n);
> /* M2_N2 registers to be set only for gen < 8 (M2_N2 available
> - * for gen < 8) and if DRRS is supported (to make sure the
> - * registers are not unnecessarily accessed).
> + * for gen < 8 and CHV) and if DRRS is supported (to make sure
> + * the registers are not unnecessarily accessed).
>*/
> if (m2_n2 && (IS_CHERRYVIEW(dev_priv) ||
> INTEL_GEN(dev_priv) < 8) && crtc_state->has_drrs) {
I think what I'd really like to see is splitting the m/n and m2/n2 stuff
into two distinct pieces, and when we don't use drrs we could just
set m2_n2 = m_n, and program the everything exactly the same way as
when drrs is enabled.
Also we could nuke that "m/n vs. m2/n2" enum and just pass the correct
struct to foo_set_m_n() directly.
> @@ -8747,11 +8747,10 @@ static void intel_cpu_transcoder_get_m_n(struct
> intel_crtc *crtc,
> m_n->tu = ((I915_READ(PIPE_DATA_M1(transcoder))
> & TU_SIZE_MASK) >> TU_SIZE_SHIFT) + 1;
> /* Read M2_N2 registers only for gen < 8 (M2_N2 available for
> - * gen < 8) and if DRRS is supported (to make sure the
> - * registers are not unnecessarily read).
> + * gen < 8 and CHV).
>*/
> - if (m2_n2 && INTEL_GEN(dev_priv) < 8 &&
> - crtc->config->has_drrs) {
> + if (m2_n2 && (INTEL_GEN(dev_priv) < 8 ||
> + IS_CHERRYVIEW(dev_priv))) {
I think this is maybe the third installment of this check. Could
perhaps use a small has_m2_n2() helper to avoid the repetition?
Either way
Reviewed-by: Ville Syrjälä
> m2_n2->link_m = I915_READ(PIPE_LINK_M2(transcoder));
> m2_n2->link_n = I915_READ(PIPE_LINK_N2(transcoder));
> m2_n2->gmch_m = I915_READ(PIPE_DATA_M2(transcoder))
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 05/10] drm/i915: Pass crtc_state to update_scanline_offset
On Thu, Oct 11, 2018 at 12:04:52PM +0200, Maarten Lankhorst wrote:
> No need to look at crtc->config when we have crtc_state in the caller.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7812fab31646..eaf522ef2927 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12127,8 +12127,9 @@ intel_modeset_verify_disabled(struct drm_device *dev,
> verify_disabled_dpll_state(dev);
> }
>
> -static void update_scanline_offset(struct intel_crtc *crtc)
> +static void update_scanline_offset(const struct intel_crtc_state *crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
> /*
> @@ -12159,7 +12160,7 @@ static void update_scanline_offset(struct intel_crtc
> *crtc)
>* answer that's slightly in the future.
>*/
> if (IS_GEN2(dev_priv)) {
> - const struct drm_display_mode *adjusted_mode =
> &crtc->config->base.adjusted_mode;
> + const struct drm_display_mode *adjusted_mode =
> &crtc_state->base.adjusted_mode;
> int vtotal;
>
> vtotal = adjusted_mode->crtc_vtotal;
> @@ -12168,7 +12169,7 @@ static void update_scanline_offset(struct intel_crtc
> *crtc)
>
> crtc->scanline_offset = vtotal - 1;
> } else if (HAS_DDI(dev_priv) &&
> -intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) {
> +intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> crtc->scanline_offset = 2;
> } else
> crtc->scanline_offset = 1;
> @@ -12522,7 +12523,7 @@ static void intel_update_crtc(struct drm_crtc *crtc,
>to_intel_plane(crtc->primary));
>
> if (modeset) {
> - update_scanline_offset(intel_crtc);
> + update_scanline_offset(pipe_config);
> dev_priv->display.crtc_enable(pipe_config, state);
>
> /* vblanks work again, re-enable pipe CRC. */
> @@ -15868,7 +15869,7 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
>
> drm_calc_timestamping_constants(&crtc->base,
>
> &crtc_state->base.adjusted_mode);
> - update_scanline_offset(crtc);
> + update_scanline_offset(crtc_state);
> }
>
> dev_priv->min_cdclk[crtc->pipe] = min_cdclk;
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 06/10] drm/i915: Remove crtc->config dereferences in intel_sanitize_crtc
On Thu, Oct 11, 2018 at 12:04:53PM +0200, Maarten Lankhorst wrote:
> We know the crtc is idle because we're at the beginning of sanitization,
> so just dereference crtc->state instead.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index eaf522ef2927..19d7714df021 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15565,7 +15565,8 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc,
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> - enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
> + struct intel_crtc_state *crtc_state =
> to_intel_crtc_state(crtc->base.state);
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>
> /* Clear any frame start delays used for debugging left by the BIOS */
> if (crtc->active && !transcoder_is_dsi(cpu_transcoder)) {
> @@ -15575,7 +15576,7 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc,
> I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
> }
>
> - if (crtc->active) {
> + if (crtc_state->base.active) {
> struct intel_plane *plane;
>
> /* Disable everything but the primary plane */
> @@ -15591,10 +15592,10 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc,
>
> /* Adjust the state of the output pipe according to whether we
>* have active connectors/encoders. */
> - if (crtc->active && !intel_crtc_has_encoders(crtc))
> + if (crtc_state->base.active && !intel_crtc_has_encoders(crtc))
> intel_crtc_disable_noatomic(&crtc->base, ctx);
>
> - if (crtc->active || HAS_GMCH_DISPLAY(dev_priv)) {
> + if (crtc_state->base.active || HAS_GMCH_DISPLAY(dev_priv)) {
> /*
>* We start out with underrun reporting disabled to avoid races.
>* For correct bookkeeping mark this on active crtcs.
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 09/10] drm/i915: Pass crtc_state to ivybridge_update_fdi_bc_bifurcation
On Thu, Oct 11, 2018 at 12:04:56PM +0200, Maarten Lankhorst wrote:
> We have to look at crtc_state, so pass that instead.
> Also cleanup the use of dev vs dev_priv, we really want to pass along
> dev_priv.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ad1694c4d947..ad2c207d18bb 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4633,9 +4633,8 @@ static void ironlake_pch_transcoder_set_timings(const
> struct intel_crtc_state *c
> I915_READ(VSYNCSHIFT(cpu_transcoder)));
> }
>
> -static void cpt_set_fdi_bc_bifurcation(struct drm_device *dev, bool enable)
> +static void cpt_set_fdi_bc_bifurcation(struct drm_i915_private *dev_priv,
> bool enable)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> uint32_t temp;
>
> temp = I915_READ(SOUTH_CHICKEN1);
> @@ -4654,22 +4653,23 @@ static void cpt_set_fdi_bc_bifurcation(struct
> drm_device *dev, bool enable)
> POSTING_READ(SOUTH_CHICKEN1);
> }
>
> -static void ivybridge_update_fdi_bc_bifurcation(struct intel_crtc
> *intel_crtc)
> +static void ivybridge_update_fdi_bc_bifurcation(const struct
> intel_crtc_state *crtc_state)
> {
> - struct drm_device *dev = intel_crtc->base.dev;
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
> - switch (intel_crtc->pipe) {
> + switch (crtc->pipe) {
> case PIPE_A:
> break;
> case PIPE_B:
> - if (intel_crtc->config->fdi_lanes > 2)
> - cpt_set_fdi_bc_bifurcation(dev, false);
> + if (crtc_state->fdi_lanes > 2)
> + cpt_set_fdi_bc_bifurcation(dev_priv, false);
> else
> - cpt_set_fdi_bc_bifurcation(dev, true);
> + cpt_set_fdi_bc_bifurcation(dev_priv, true);
>
> break;
> case PIPE_C:
> - cpt_set_fdi_bc_bifurcation(dev, true);
> + cpt_set_fdi_bc_bifurcation(dev_priv, true);
>
> break;
> default:
> @@ -4726,7 +4726,7 @@ static void ironlake_pch_enable(const struct
> intel_atomic_state *state,
> assert_pch_transcoder_disabled(dev_priv, pipe);
>
> if (IS_IVYBRIDGE(dev_priv))
> - ivybridge_update_fdi_bc_bifurcation(crtc);
> + ivybridge_update_fdi_bc_bifurcation(crtc_state);
>
> /* Write the TU size bits before fdi link training, so that error
>* detection works. */
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 08/10] drm/i915: Pass crtc_state to lpt_program_iclkip
On Thu, Oct 11, 2018 at 12:04:55PM +0200, Maarten Lankhorst wrote:
> Instead of derferencing crtc->config, look at crtc_state.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index cbe70bc4d02d..ad1694c4d947 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4494,10 +4494,11 @@ void lpt_disable_iclkip(struct drm_i915_private
> *dev_priv)
> }
>
> /* Program iCLKIP clock to the desired frequency */
> -static void lpt_program_iclkip(struct intel_crtc *crtc)
> +static void lpt_program_iclkip(const struct intel_crtc_state *crtc_state)
> {
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - int clock = crtc->config->base.adjusted_mode.crtc_clock;
> + int clock = crtc_state->base.adjusted_mode.crtc_clock;
> u32 divsel, phaseinc, auxdiv, phasedir = 0;
> u32 temp;
>
> @@ -4806,7 +4807,7 @@ static void lpt_pch_enable(const struct
> intel_atomic_state *state,
>
> assert_pch_transcoder_disabled(dev_priv, PIPE_A);
>
> - lpt_program_iclkip(crtc);
> + lpt_program_iclkip(crtc_state);
>
> /* Set transcoder timing. */
> ironlake_pch_transcoder_set_timings(crtc_state, PIPE_A);
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 10/10] drm/i915: Remove crtc->active from crtc_enable callbacks
On Thu, Oct 11, 2018 at 12:04:57PM +0200, Maarten Lankhorst wrote:
> Now that most of the driver is atomic, we no longer need to worry
> about setting crtc->active right before actually enabling the pipe.
Hmm. I think we need at least that wait_for_vblank_if_active() change
we discussed. And maybe there's something in the watermark code that
depends on this being more or less accurate indication of thw hw state.
That probably needs some actual thought.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 21 +
> 1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ad2c207d18bb..0e4bdd5c337e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5585,9 +5585,6 @@ static void ironlake_crtc_enable(struct
> intel_crtc_state *pipe_config,
> struct intel_atomic_state *old_intel_state =
> to_intel_atomic_state(old_state);
>
> - if (WARN_ON(intel_crtc->active))
> - return;
> -
> /*
>* Sometimes spurious CPU pipe underruns happen during FDI
>* training, at least with VGA+HDMI cloning. Suppress them.
> @@ -5617,8 +5614,6 @@ static void ironlake_crtc_enable(struct
> intel_crtc_state *pipe_config,
>
> ironlake_set_pipeconf(pipe_config);
>
> - intel_crtc->active = true;
> -
> intel_encoders_pre_enable(crtc, pipe_config, old_state);
>
> if (pipe_config->has_pch_encoder) {
> @@ -5715,9 +5710,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> bool psl_clkgate_wa;
> u32 pipe_chicken;
>
> - if (WARN_ON(intel_crtc->active))
> - return;
> -
> intel_encoders_pre_pll_enable(crtc, pipe_config, old_state);
>
> if (pipe_config->shared_dpll)
> @@ -5754,8 +5746,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
>
> intel_color_set_csc(&pipe_config->base);
>
> - intel_crtc->active = true;
> -
> /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
> psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
>pipe_config->pch_pfit.enabled;
> @@ -6067,9 +6057,6 @@ static void valleyview_crtc_enable(struct
> intel_crtc_state *pipe_config,
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> int pipe = intel_crtc->pipe;
>
> - if (WARN_ON(intel_crtc->active))
> - return;
> -
> if (intel_crtc_has_dp_encoder(pipe_config))
> intel_dp_set_m_n(pipe_config, M1_N1);
>
> @@ -6085,8 +6072,6 @@ static void valleyview_crtc_enable(struct
> intel_crtc_state *pipe_config,
>
> intel_color_set_csc(&pipe_config->base);
>
> - intel_crtc->active = true;
> -
> intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
>
> intel_encoders_pre_pll_enable(crtc, pipe_config, old_state);
> @@ -6135,9 +6120,6 @@ static void i9xx_crtc_enable(struct intel_crtc_state
> *pipe_config,
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> enum pipe pipe = intel_crtc->pipe;
>
> - if (WARN_ON(intel_crtc->active))
> - return;
> -
> i9xx_set_pll_dividers(pipe_config);
>
> if (intel_crtc_has_dp_encoder(pipe_config))
> @@ -6148,8 +6130,6 @@ static void i9xx_crtc_enable(struct intel_crtc_state
> *pipe_config,
>
> i9xx_set_pipeconf(pipe_config);
>
> - intel_crtc->active = true;
> -
> if (!IS_GEN2(dev_priv))
> intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
>
> @@ -12525,6 +12505,7 @@ static void intel_update_crtc(struct drm_crtc *crtc,
>
> if (modeset) {
> update_scanline_offset(pipe_config);
> + intel_crtc->active = true;
> dev_priv->display.crtc_enable(pipe_config, state);
>
> /* vblanks work again, re-enable pipe CRC. */
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 07/10] drm/i915: Remove crtc->config dereferences in intel_modeset_setup_hw_state
On Thu, Oct 11, 2018 at 12:04:54PM +0200, Maarten Lankhorst wrote:
> The CRTC is idle at this point, so we can dereference crtc->state safely.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 19d7714df021..cbe70bc4d02d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15934,6 +15934,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_crtc *crtc;
> + struct intel_crtc_state *crtc_state;
Can be moved into narrower scope.
> struct intel_encoder *encoder;
> int i;
>
> @@ -15952,7 +15953,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
> for_each_intel_crtc(&dev_priv->drm, crtc) {
> drm_crtc_vblank_reset(&crtc->base);
>
> - if (crtc->active)
> + if (crtc->base.state->active)
> drm_crtc_vblank_on(&crtc->base);
> }
>
> @@ -15961,9 +15962,10 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
> for_each_intel_encoder(dev, encoder)
> intel_sanitize_encoder(encoder);
>
> - for_each_intel_crtc(&dev_priv->drm, crtc) {
> + for_each_intel_crtc(dev, crtc) {
I'd keep the dev_priv->drm, because we should just change the function
to take the dev_priv directly.
Apart from those
Reviewed-by: Ville Syrjälä
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> intel_sanitize_crtc(crtc, ctx);
> - intel_dump_pipe_config(crtc, crtc->config,
> + intel_dump_pipe_config(crtc, crtc_state,
> "[setup_hw_state]");
> }
>
> @@ -15997,7 +15999,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
> for_each_intel_crtc(dev, crtc) {
> u64 put_domains;
>
> - put_domains = modeset_get_crtc_power_domains(&crtc->base,
> crtc->config);
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> + put_domains = modeset_get_crtc_power_domains(&crtc->base,
> crtc_state);
> if (WARN_ON(put_domains))
> modeset_put_power_domains(dev_priv, put_domains);
> }
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 05/12] drm/i915: Add DEFINE_SNPRINTF_ARRAY()
On Wed, 10 Oct 2018, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Templatize snprintf_int_array() to allow us to print
> different kinds of arrays without having to type all
> the boilerplate for the snprintf() loop.
I might just feel happier about duplicating the boilerplate...
BR,
Jani.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_utils.h | 16
> drivers/gpu/drm/i915/intel_dp.c | 17 ++---
> 2 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index 5858a43e19da..079aefa20bee 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -161,4 +161,20 @@ static inline const char *enableddisabled(bool v)
> return v ? "enabled" : "disabled";
> }
>
> +#define DEFINE_SNPRINTF_ARRAY(name, type, values, index, fmt, ...) \
> +void name(char *_str, size_t _len, const type *values, int _nelems) \
> +{ \
> + int index; \
> + if (_len) \
> + _str[0] = '\0'; \
> + for (index = 0; index < _nelems; index++) { \
> + int _r = snprintf(_str, _len, "%s" fmt, \
> + index ? ", " : "", __VA_ARGS__); \
> + if (_r >= _len) \
> + return; \
> + _str += _r; \
> + _len -= _r; \
> + } \
> +}
> +
> #endif /* !__I915_UTILS_H */
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 13ff89be6ad6..dd8634b40179 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1774,21 +1774,8 @@ intel_dp_set_clock(struct intel_encoder *encoder,
> }
> }
>
> -static void snprintf_int_array(char *str, size_t len,
> -const int *array, int nelem)
> -{
> - int i;
> -
> - str[0] = '\0';
> -
> - for (i = 0; i < nelem; i++) {
> - int r = snprintf(str, len, "%s%d", i ? ", " : "", array[i]);
> - if (r >= len)
> - return;
> - str += r;
> - len -= r;
> - }
> -}
> +static DEFINE_SNPRINTF_ARRAY(snprintf_int_array,
> + int, array, i, "%d", array[i]);
>
> static void intel_dp_print_rates(struct intel_dp *intel_dp)
> {
--
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] drm/i915: Fix i915_driver_init_mmio error path
In case of the error we missed to call i915_mmio_cleanup that matches earlier call to i915_mmio_setup. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 19302342..baac35f 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1030,6 +1030,7 @@ static int i915_driver_init_mmio(struct drm_i915_private *dev_priv) err_uncore: intel_uncore_fini(dev_priv); + i915_mmio_cleanup(dev_priv); err_bridge: pci_dev_put(dev_priv->bridge_dev); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix i915_driver_init_mmio error path
Quoting Michal Wajdeczko (2018-10-11 13:19:51) > In case of the error we missed to call i915_mmio_cleanup > that matches earlier call to i915_mmio_setup. True, doesn't look fatal atm; worst being we left the register bar mmapped (which would be ok as we map it again using the same constraints on next load) and left the mchbar flagged as active (if we enabled it on i915/i965). We should pair this with a patch to add a i915_inject_load_failure() to intel_engine_init_mmio. > Signed-off-by: Michal Wajdeczko > Cc: Joonas Lahtinen > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix i915_driver_init_mmio error path
Michal Wajdeczko writes: > In case of the error we missed to call i915_mmio_cleanup > that matches earlier call to i915_mmio_setup. > > Signed-off-by: Michal Wajdeczko > Cc: Joonas Lahtinen > Cc: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 19302342..baac35f 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1030,6 +1030,7 @@ static int i915_driver_init_mmio(struct > drm_i915_private *dev_priv) > > err_uncore: > intel_uncore_fini(dev_priv); > + i915_mmio_cleanup(dev_priv); > err_bridge: > pci_dev_put(dev_priv->bridge_dev); > > -- > 1.9.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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev4)
== Series Details ==
Series: drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture
(rev4)
URL : https://patchwork.freedesktop.org/series/34969/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4969 -> Patchwork_10427 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/34969/revisions/4/mbox/
== Known issues ==
Here are the changes found in Patchwork_10427 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_flip@basic-flip-vs-modeset:
fi-hsw-4770r: PASS -> DMESG-WARN (fdo#105602) +1
igt@kms_frontbuffer_tracking@basic:
{fi-icl-u2}:SKIP -> FAIL (fdo#103167)
fi-byt-clapper: PASS -> FAIL (fdo#103167)
igt@kms_pipe_crc_basic@read-crc-pipe-b:
fi-byt-clapper: PASS -> FAIL (fdo#107362)
Possible fixes
igt@gem_exec_suspend@basic-s3:
fi-cfl-8109u: INCOMPLETE (fdo#107187, fdo#108126) -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: WARN (fdo#102672) -> PASS
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
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#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126
== Participating hosts (44 -> 39) ==
Missing(5): fi-bsw-cyan fi-ilk-m540 fi-byt-squawks fi-gdg-551 fi-pnv-d510
== Build changes ==
* Linux: CI_DRM_4969 -> Patchwork_10427
CI_DRM_4969: 1121d2889e57dedacc0885deaaa9de614832e62f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10427: ea61179bb5e951736f94721fa7359e98e78a3906 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ea61179bb5e9 drm/i915: Prevent machine hang from Broxton's vtd w/a and error
capture
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10427/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/gem_set_tiling_vs_pwrite: Skip on unknown swizzling
From: Tvrtko Ursulin
Same as in commit 78071c2fa53d ("igt/gem_tiled_partial_pwrite_pread: Check
for known swizzling"), to be able to compare the bo against the test
pattern we need to skip the test if the swizzling is not compatible.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102575
Cc: Chris Wilson
---
Eeek confidence level low - is this correct?
---
tests/gem_set_tiling_vs_pwrite.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/gem_set_tiling_vs_pwrite.c b/tests/gem_set_tiling_vs_pwrite.c
index f0126b6484b7..3be908dbd103 100644
--- a/tests/gem_set_tiling_vs_pwrite.c
+++ b/tests/gem_set_tiling_vs_pwrite.c
@@ -42,6 +42,18 @@ IGT_TEST_DESCRIPTION("Check set_tiling vs pwrite
coherency.");
#define OBJECT_SIZE (1024*1024)
#define TEST_STRIDE (1024*4)
+static bool known_swizzling(int fd, uint32_t handle)
+{
+ struct drm_i915_gem_get_tiling arg = {
+ .handle = handle,
+ };
+
+ if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING, &arg))
+ return false;
+
+ return arg.phys_swizzle_mode == arg.swizzle_mode;
+}
+
/**
* Testcase: Check set_tiling vs pwrite coherency
*/
@@ -66,6 +78,12 @@ igt_simple_main
gem_set_tiling(fd, handle, I915_TILING_X, TEST_STRIDE);
+ /*
+* As we want to compare our template pattern against
+* the target bo, we need consistent swizzling on both.
+*/
+ igt_require(known_swizzling(fd, handle));
+
/* touch it */
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
*ptr = 0xdeadbeef;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_set_tiling_vs_pwrite: Skip on unknown swizzling
Quoting Tvrtko Ursulin (2018-10-11 13:30:27)
> From: Tvrtko Ursulin
>
> Same as in commit 78071c2fa53d ("igt/gem_tiled_partial_pwrite_pread: Check
> for known swizzling"), to be able to compare the bo against the test
> pattern we need to skip the test if the swizzling is not compatible.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102575
> Cc: Chris Wilson
> ---
> Eeek confidence level low - is this correct?
Actually this is a slightly more subtle problem,
https://patchwork.freedesktop.org/patch/240327/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_set_tiling_vs_pwrite: Skip on unknown swizzling
On 11/10/2018 13:34, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-11 13:30:27)
From: Tvrtko Ursulin
Same as in commit 78071c2fa53d ("igt/gem_tiled_partial_pwrite_pread: Check
for known swizzling"), to be able to compare the bo against the test
pattern we need to skip the test if the swizzling is not compatible.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102575
Cc: Chris Wilson
---
Eeek confidence level low - is this correct?
Actually this is a slightly more subtle problem,
https://patchwork.freedesktop.org/patch/240327/
So assuming your patch is in, this IGT cannot actually work if any
swizzling is in effect? Or without your patch, it should skip based on
known_swizzling? Or is even that not enough?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Add DEFINE_SNPRINTF_ARRAY()
On Thu, Oct 11, 2018 at 03:14:41PM +0300, Jani Nikula wrote:
> On Wed, 10 Oct 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Templatize snprintf_int_array() to allow us to print
> > different kinds of arrays without having to type all
> > the boilerplate for the snprintf() loop.
>
> I might just feel happier about duplicating the boilerplate...
How about when the third user appears? :)
Not sure I have a third user for this actually.
snprintf_output_types() is pretty close, and there are other
bitmask I'd probably like to decode. But I couldn't immediately
think of a nice way to handle bitmasks and arrays in the same
function.
>
> BR,
> Jani.
>
>
>
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_utils.h | 16
> > drivers/gpu/drm/i915/intel_dp.c | 17 ++---
> > 2 files changed, 18 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_utils.h
> > b/drivers/gpu/drm/i915/i915_utils.h
> > index 5858a43e19da..079aefa20bee 100644
> > --- a/drivers/gpu/drm/i915/i915_utils.h
> > +++ b/drivers/gpu/drm/i915/i915_utils.h
> > @@ -161,4 +161,20 @@ static inline const char *enableddisabled(bool v)
> > return v ? "enabled" : "disabled";
> > }
> >
> > +#define DEFINE_SNPRINTF_ARRAY(name, type, values, index, fmt, ...) \
> > +void name(char *_str, size_t _len, const type *values, int _nelems) \
> > +{ \
> > + int index; \
> > + if (_len) \
> > + _str[0] = '\0'; \
> > + for (index = 0; index < _nelems; index++) { \
> > + int _r = snprintf(_str, _len, "%s" fmt, \
> > + index ? ", " : "", __VA_ARGS__); \
> > + if (_r >= _len) \
> > + return; \
> > + _str += _r; \
> > + _len -= _r; \
> > + } \
> > +}
> > +
> > #endif /* !__I915_UTILS_H */
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 13ff89be6ad6..dd8634b40179 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1774,21 +1774,8 @@ intel_dp_set_clock(struct intel_encoder *encoder,
> > }
> > }
> >
> > -static void snprintf_int_array(char *str, size_t len,
> > - const int *array, int nelem)
> > -{
> > - int i;
> > -
> > - str[0] = '\0';
> > -
> > - for (i = 0; i < nelem; i++) {
> > - int r = snprintf(str, len, "%s%d", i ? ", " : "", array[i]);
> > - if (r >= len)
> > - return;
> > - str += r;
> > - len -= r;
> > - }
> > -}
> > +static DEFINE_SNPRINTF_ARRAY(snprintf_int_array,
> > +int, array, i, "%d", array[i]);
> >
> > static void intel_dp_print_rates(struct intel_dp *intel_dp)
> > {
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_set_tiling_vs_pwrite: Skip on unknown swizzling
Quoting Tvrtko Ursulin (2018-10-11 13:42:31)
>
> On 11/10/2018 13:34, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-10-11 13:30:27)
> >> From: Tvrtko Ursulin
> >>
> >> Same as in commit 78071c2fa53d ("igt/gem_tiled_partial_pwrite_pread: Check
> >> for known swizzling"), to be able to compare the bo against the test
> >> pattern we need to skip the test if the swizzling is not compatible.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102575
> >> Cc: Chris Wilson
> >> ---
> >> Eeek confidence level low - is this correct?
> >
> > Actually this is a slightly more subtle problem,
> > https://patchwork.freedesktop.org/patch/240327/
>
> So assuming your patch is in, this IGT cannot actually work if any
> swizzling is in effect?
With the kernel patch, pwrite is a pure linear write to physical
address, not guaranteeing layout on the gpu (the gpu sees it through the
tile + swizzle combo). So set-tiling no longer affects pwrite and the
test should see identical in/out.
> Or without your patch, it should skip based on
> known_swizzling? Or is even that not enough?
Without the patch, we would need to take swizzling into account and so
skip as we cannot know the swizzling in this case. The test illustrates
that currently we do the swizzling asymmetrically, our API is bust. The
test further illustrates that at times we cannot even know when swizzling
is required (due to L-shape eccentricities and the swizzling changing
within an object) and so the concept of handling swizzling on the API
boundary on behalf of the user is unworkable.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/3] drm/i915/perf: Add OA buffer size uAPI parameter
Hi all, This version drops a patch that wasn't necessary and simplify the OA buffer size exponent as recommended by Chris (Thanks!). Cheers, Lionel Landwerlin (3): drm/i915/perf: remove redundant oa buffer initialization drm/i915/perf: pass stream to vfuncs when possible drm/i915/perf: add a parameter to control the size of OA buffer drivers/gpu/drm/i915/i915_drv.h | 25 +- drivers/gpu/drm/i915/i915_perf.c | 141 --- drivers/gpu/drm/i915/i915_reg.h | 2 + include/uapi/drm/i915_drm.h | 8 ++ 4 files changed, 104 insertions(+), 72 deletions(-) -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915/perf: add a parameter to control the size of OA buffer
The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.
In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buffer to the minimum
size to avoid consuming memory which won't be used by the driver.
v2: Simplify oa buffer size exponent selection (Chris)
Reuse vma size field (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 92 ++--
drivers/gpu/drm/i915/i915_reg.h | 2 +
include/uapi/drm/i915_drm.h | 8 +++
4 files changed, 75 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65eaac2d7e3c..f12770bd4858 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2053,6 +2053,7 @@ struct drm_i915_private {
u32 last_ctx_id;
int format;
int format_size;
+ int size_exponent;
/**
* Locks reads and writes to all head/tail state
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 88f3f9b6a353..29737c627e1c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -212,13 +212,7 @@
#include "i915_oa_icl.h"
#include "intel_lrc_reg.h"
-/* HW requires this to be a power of two, between 128k and 16M, though driver
- * is currently generally designed assuming the largest 16M size is used such
- * that the overflow cases are unlikely in normal operation.
- */
-#define OA_BUFFER_SIZE SZ_16M
-
-#define OA_TAKEN(tail, head) ((tail - head) & (OA_BUFFER_SIZE - 1))
+#define OA_TAKEN(tail, head) ((tail - head) &
(dev_priv->perf.oa.oa_buffer.vma->size - 1))
/**
* DOC: OA Tail Pointer Race
@@ -361,6 +355,7 @@ struct perf_open_properties {
int oa_format;
bool oa_periodic;
int oa_period_exponent;
+ u32 oa_buffer_size_exponent;
};
static void free_oa_config(struct drm_i915_private *dev_priv,
@@ -523,7 +518,7 @@ static bool oa_buffer_check_unlocked(struct
drm_i915_private *dev_priv)
* could put the tail out of bounds...
*/
if (hw_tail >= gtt_offset &&
- hw_tail < (gtt_offset + OA_BUFFER_SIZE)) {
+ hw_tail < (gtt_offset +
dev_priv->perf.oa.oa_buffer.vma->size)) {
dev_priv->perf.oa.oa_buffer.tails[!aged_idx].offset =
aging_tail = hw_tail;
dev_priv->perf.oa.oa_buffer.aging_timestamp = now;
@@ -652,7 +647,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
u8 *oa_buf_base = dev_priv->perf.oa.oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma);
- u32 mask = (OA_BUFFER_SIZE - 1);
+ u32 mask = (dev_priv->perf.oa.oa_buffer.vma->size - 1);
size_t start_offset = *offset;
unsigned long flags;
unsigned int aged_tail_idx;
@@ -692,8 +687,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* only be incremented by multiples of the report size (notably also
* all a power of two).
*/
- if (WARN_ONCE(head > OA_BUFFER_SIZE || head % report_size ||
- tail > OA_BUFFER_SIZE || tail % report_size,
+ if (WARN_ONCE(head > dev_priv->perf.oa.oa_buffer.vma->size || head %
report_size ||
+ tail > dev_priv->perf.oa.oa_buffer.vma->size || tail %
report_size,
"Inconsistent OA buffer pointers: head = %u, tail = %u\n",
head, tail))
return -EIO;
@@ -716,7 +711,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* here would imply a driver bug that would result
* in an overrun.
*/
- if (WARN_ON((OA_BUFFER_SIZE - head) < report_size)) {
+ if (WARN_ON((dev_priv->perf.oa.oa_buffer.vma->size - head) <
report_size)) {
DRM_ERROR("Spurious OA head ptr: non-integral report
offset\n");
break;
}
@@ -941,7 +936,7 @@ static int gen7_append_oa_reports(struct i915_perf_stream
*stream,
int report_size = dev_priv->perf.oa.oa_buffer.format_size;
u8 *oa_buf_base = dev_priv->perf.oa.oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma);
- u32 mask = (OA_BUFFER_SIZE - 1);
+ u32 mask = (dev_priv->perf.oa.oa_buffer.vma->size - 1);
size_t start_offset = *offset;
unsigned long flags;
unsigned int age
[Intel-gfx] [PATCH v2 1/3] drm/i915/perf: remove redundant oa buffer initialization
We initialize the OA buffer everytime we enable the OA unit (first call in
gen[78]_oa_enable), so we don't need to initialize when preparing the metric
set.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 17 -
drivers/gpu/drm/i915/i915_perf.c | 6 +-
2 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63ce0da4e723..eef7c811bd8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1529,23 +1529,6 @@ struct i915_oa_ops {
*/
bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
- /**
-* @init_oa_buffer: Resets the head and tail pointers of the
-* circular buffer for periodic OA reports.
-*
-* Called when first opening a stream for OA metrics, but also may be
-* called in response to an OA buffer overflow or other error
-* condition.
-*
-* Note it may be necessary to clear the full OA buffer here as part of
-* maintaining the invariable that new reports must be written to
-* zeroed memory for us to be able to reliable detect if an expected
-* report has not yet landed in memory. (At least on Haswell the OA
-* buffer tail pointer is not synchronized with reports being visible
-* to the CPU)
-*/
- void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
-
/**
* @enable_metric_set: Selects and applies any MUX configuration to set
* up the Boolean and Custom (B/C) counters that are part of the
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 30911efd2cf7..14f7d03aabcf 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1530,8 +1530,6 @@ static int alloc_oa_buffer(struct drm_i915_private
*dev_priv)
goto err_unpin;
}
- dev_priv->perf.oa.ops.init_oa_buffer(dev_priv);
-
DRM_DEBUG_DRIVER("OA Buffer initialized, gtt offset = 0x%x, vaddr =
%p\n",
i915_ggtt_offset(dev_priv->perf.oa.oa_buffer.vma),
dev_priv->perf.oa.oa_buffer.vaddr);
@@ -2000,7 +1998,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
return -EINVAL;
}
- if (!dev_priv->perf.oa.ops.init_oa_buffer) {
+ if (!dev_priv->perf.oa.ops.enable_metric_set) {
DRM_DEBUG("OA unit not supported\n");
return -ENODEV;
}
@@ -3389,7 +3387,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.is_valid_mux_reg =
hsw_is_valid_mux_addr;
dev_priv->perf.oa.ops.is_valid_flex_reg = NULL;
- dev_priv->perf.oa.ops.init_oa_buffer = gen7_init_oa_buffer;
dev_priv->perf.oa.ops.enable_metric_set = hsw_enable_metric_set;
dev_priv->perf.oa.ops.disable_metric_set =
hsw_disable_metric_set;
dev_priv->perf.oa.ops.oa_enable = gen7_oa_enable;
@@ -3408,7 +3405,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
*/
dev_priv->perf.oa.oa_formats = gen8_plus_oa_formats;
- dev_priv->perf.oa.ops.init_oa_buffer = gen8_init_oa_buffer;
dev_priv->perf.oa.ops.oa_enable = gen8_oa_enable;
dev_priv->perf.oa.ops.oa_disable = gen8_oa_disable;
dev_priv->perf.oa.ops.read = gen8_oa_read;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915/perf: pass stream to vfuncs when possible
We want to use some of the properties of the perf stream to program
the hardware in a later commit.
v2: Pass only perf stream as argument (Matthew)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++---
drivers/gpu/drm/i915/i915_perf.c | 43 +++-
2 files changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eef7c811bd8f..65eaac2d7e3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1535,8 +1535,7 @@ struct i915_oa_ops {
* counter reports being sampled. May apply system constraints such as
* disabling EU clock gating as required.
*/
- int (*enable_metric_set)(struct drm_i915_private *dev_priv,
-const struct i915_oa_config *oa_config);
+ int (*enable_metric_set)(struct i915_perf_stream *stream);
/**
* @disable_metric_set: Remove system constraints associated with using
@@ -1547,12 +1546,12 @@ struct i915_oa_ops {
/**
* @oa_enable: Enable periodic sampling
*/
- void (*oa_enable)(struct drm_i915_private *dev_priv);
+ void (*oa_enable)(struct i915_perf_stream *stream);
/**
* @oa_disable: Disable periodic sampling
*/
- void (*oa_disable)(struct drm_i915_private *dev_priv);
+ void (*oa_disable)(struct i915_perf_stream *stream);
/**
* @read: Copy data from the circular OA buffer into a given userspace
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 14f7d03aabcf..88f3f9b6a353 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -890,8 +890,8 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",
dev_priv->perf.oa.period_exponent);
- dev_priv->perf.oa.ops.oa_disable(dev_priv);
- dev_priv->perf.oa.ops.oa_enable(dev_priv);
+ dev_priv->perf.oa.ops.oa_disable(stream);
+ dev_priv->perf.oa.ops.oa_enable(stream);
/*
* Note: .oa_enable() is expected to re-init the oabuffer and
@@ -1114,8 +1114,8 @@ static int gen7_oa_read(struct i915_perf_stream *stream,
DRM_DEBUG("OA buffer overflow (exponent = %d): force restart\n",
dev_priv->perf.oa.period_exponent);
- dev_priv->perf.oa.ops.oa_disable(dev_priv);
- dev_priv->perf.oa.ops.oa_enable(dev_priv);
+ dev_priv->perf.oa.ops.oa_disable(stream);
+ dev_priv->perf.oa.ops.oa_enable(stream);
oastatus1 = I915_READ(GEN7_OASTATUS1);
}
@@ -1563,9 +1563,11 @@ static void config_oa_regs(struct drm_i915_private
*dev_priv,
}
}
-static int hsw_enable_metric_set(struct drm_i915_private *dev_priv,
-const struct i915_oa_config *oa_config)
+static int hsw_enable_metric_set(struct i915_perf_stream *stream)
{
+ struct drm_i915_private *dev_priv = stream->dev_priv;
+ const struct i915_oa_config *oa_config = stream->oa_config;
+
/* PRM:
*
* OA unit is using “crclk” for its functionality. When trunk
@@ -1767,9 +1769,10 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
return 0;
}
-static int gen8_enable_metric_set(struct drm_i915_private *dev_priv,
- const struct i915_oa_config *oa_config)
+static int gen8_enable_metric_set(struct i915_perf_stream *stream)
{
+ struct drm_i915_private *dev_priv = stream->dev_priv;
+ const struct i915_oa_config *oa_config = stream->oa_config;
int ret;
/*
@@ -1837,10 +1840,10 @@ static void gen10_disable_metric_set(struct
drm_i915_private *dev_priv)
I915_READ(RPM_CONFIG1) & ~GEN10_GT_NOA_ENABLE);
}
-static void gen7_oa_enable(struct drm_i915_private *dev_priv)
+static void gen7_oa_enable(struct i915_perf_stream *stream)
{
- struct i915_gem_context *ctx =
- dev_priv->perf.oa.exclusive_stream->ctx;
+ struct drm_i915_private *dev_priv = stream->dev_priv;
+ struct i915_gem_context *ctx = stream->ctx;
u32 ctx_id = dev_priv->perf.oa.specific_ctx_id;
bool periodic = dev_priv->perf.oa.periodic;
u32 period_exponent = dev_priv->perf.oa.period_exponent;
@@ -1867,8 +1870,9 @@ static void gen7_oa_enable(struct drm_i915_private
*dev_priv)
GEN7_OACONTROL_ENABLE);
}
-static void gen8_oa_enable(struct drm_i915_private *dev_priv)
+static void gen8_oa_enable(struct i915_perf_stream *stream)
{
+ struct drm_i915_private *dev_priv = stream->dev_priv;
u32 report_format = dev_priv->perf.oa.oa_buffer.format;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix i915_driver_init_mmio error path
== Series Details == Series: drm/i915: Fix i915_driver_init_mmio error path URL : https://patchwork.freedesktop.org/series/50864/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4969 -> Patchwork_10428 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50864/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10428 that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: fi-skl-guc: PASS -> DMESG-FAIL (fdo#106685) Possible fixes igt@gem_exec_suspend@basic-s3: fi-cfl-8109u: INCOMPLETE (fdo#108126, fdo#107187) -> PASS igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: WARN (fdo#102672) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS +1 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#106685 https://bugs.freedesktop.org/show_bug.cgi?id=106685 fdo#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126 == Participating hosts (44 -> 41) == Missing(3): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan == Build changes == * Linux: CI_DRM_4969 -> Patchwork_10428 CI_DRM_4969: 1121d2889e57dedacc0885deaaa9de614832e62f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10428: cde7e55e0ee257b62d5f28c657586b1c7b2e3f2e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cde7e55e0ee2 drm/i915: Fix i915_driver_init_mmio error path == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10428/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Inject load failure inside intel_engines_init_mmio
We need extra load failure point to better test error path in
i915_driver_init_mmio.
Suggested-by: Chris Wilson
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1c6143b..f27dbe2 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -337,6 +337,9 @@ int intel_engines_init_mmio(struct drm_i915_private
*dev_priv)
WARN_ON(ring_mask &
GENMASK(BITS_PER_TYPE(mask) - 1, I915_NUM_ENGINES));
+ if (i915_inject_load_failure())
+ return -ENODEV;
+
for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
if (!HAS_ENGINE(dev_priv, i))
continue;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Fix i915_driver_init_mmio error path
In case of the error we missed to call i915_mmio_cleanup that matches earlier call to i915_mmio_setup. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Mika Kuoppala Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 19302342..baac35f 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1030,6 +1030,7 @@ static int i915_driver_init_mmio(struct drm_i915_private *dev_priv) err_uncore: intel_uncore_fini(dev_priv); + i915_mmio_cleanup(dev_priv); err_bridge: pci_dev_put(dev_priv->bridge_dev); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: Add OA buffer size uAPI parameter (rev2)
== Series Details == Series: drm/i915/perf: Add OA buffer size uAPI parameter (rev2) URL : https://patchwork.freedesktop.org/series/50810/ State : warning == Summary == $ dim checkpatch origin/drm-tip c4fba7f16af5 drm/i915/perf: remove redundant oa buffer initialization -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: gen[78]_oa_enable), so we don't need to initialize when preparing the metric total: 0 errors, 1 warnings, 0 checks, 53 lines checked e10c7f9d8db4 drm/i915/perf: pass stream to vfuncs when possible 7854511c4c68 drm/i915/perf: add a parameter to control the size of OA buffer -:46: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'tail' may be better as '(tail)' to avoid precedence issues #46: FILE: drivers/gpu/drm/i915/i915_perf.c:215: +#define OA_TAKEN(tail, head) ((tail - head) & (dev_priv->perf.oa.oa_buffer.vma->size - 1)) -:46: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'head' may be better as '(head)' to avoid precedence issues #46: FILE: drivers/gpu/drm/i915/i915_perf.c:215: +#define OA_TAKEN(tail, head) ((tail - head) & (dev_priv->perf.oa.oa_buffer.vma->size - 1)) total: 0 errors, 0 warnings, 2 checks, 260 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: Add OA buffer size uAPI parameter (rev2)
== Series Details == Series: drm/i915/perf: Add OA buffer size uAPI parameter (rev2) URL : https://patchwork.freedesktop.org/series/50810/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/perf: remove redundant oa buffer initialization -drivers/gpu/drm/i915/selftests/../i915_drv.h:3725:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3708:16: warning: expression using sizeof(void) Commit: drm/i915/perf: pass stream to vfuncs when possible -drivers/gpu/drm/i915/selftests/../i915_drv.h:3708:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3707:16: warning: expression using sizeof(void) Commit: drm/i915/perf: add a parameter to control the size of OA buffer -O:drivers/gpu/drm/i915/i915_perf.c:1422:15: warning: memset with byte count of 16777216 -O:drivers/gpu/drm/i915/i915_perf.c:1480:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.c:2669:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_perf.
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v1,01/10] drm/i915: introduced pv capability for vgpu
== Series Details ==
Series: series starting with [v1,01/10] drm/i915: introduced pv capability for
vgpu
URL : https://patchwork.freedesktop.org/series/50851/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4968_full -> Patchwork_10421_full =
== Summary - SUCCESS ==
No regressions found.
== Known issues ==
Here are the changes found in Patchwork_10421_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@core_prop_blob@invalid-get-prop-any:
shard-snb: NOTRUN -> INCOMPLETE (fdo#105411)
igt@gem_exec_schedule@pi-ringfull-bsd:
shard-skl: NOTRUN -> FAIL (fdo#103158) +2
igt@kms_addfb_basic@bo-too-small-due-to-tiling:
shard-snb: NOTRUN -> DMESG-WARN (fdo#107469) +3
igt@kms_atomic_transition@2x-modeset-transitions-nonblocking-fencing:
shard-glk: NOTRUN -> INCOMPLETE (fdo#103359, k.org#198133)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
shard-snb: NOTRUN -> DMESG-WARN (fdo#107956) +1
igt@kms_cursor_legacy@cursora-vs-flipa-toggle:
shard-glk: PASS -> DMESG-WARN (fdo#106538, fdo#105763)
igt@kms_flip@plain-flip-fb-recreate:
shard-kbl: PASS -> FAIL (fdo#100368)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
shard-glk: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
shard-apl: PASS -> FAIL (fdo#103167) +1
igt@kms_pipe_crc_basic@read-crc-pipe-c:
shard-skl: NOTRUN -> FAIL (fdo#107362) +1
igt@kms_plane@pixel-format-pipe-c-planes:
shard-skl: NOTRUN -> DMESG-FAIL (fdo#103166, fdo#106885)
igt@kms_plane@plane-position-covered-pipe-c-planes:
shard-apl: PASS -> FAIL (fdo#103166) +2
{igt@kms_plane_alpha_blend@pipe-a-alpha-7efc}:
shard-skl: NOTRUN -> FAIL (fdo#108145) +3
{igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb}:
shard-kbl: NOTRUN -> FAIL (fdo#108145)
{igt@kms_plane_alpha_blend@pipe-c-alpha-7efc}:
shard-skl: NOTRUN -> FAIL (fdo#108146)
{igt@kms_plane_alpha_blend@pipe-c-coverage-7efc}:
shard-apl: NOTRUN -> FAIL (fdo#108146)
igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
shard-skl: NOTRUN -> FAIL (fdo#103166)
igt@kms_sysfs_edid_timing:
shard-skl: NOTRUN -> FAIL (fdo#100047)
Possible fixes
igt@drv_hangman@error-state-capture-render:
shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS
igt@gem_userptr_blits@readonly-unsync:
shard-kbl: INCOMPLETE (fdo#103665) -> PASS
igt@kms_cursor_crc@cursor-64x64-dpms:
shard-apl: FAIL (fdo#103232) -> PASS
igt@kms_flip@flip-vs-expired-vblank:
shard-kbl: FAIL (fdo#102887, fdo#105363) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
shard-apl: FAIL (fdo#103167) -> PASS +3
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
shard-glk: FAIL (fdo#103167) -> PASS +3
igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
shard-skl: INCOMPLETE (fdo#107773, fdo#104108) -> PASS +1
igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
shard-apl: FAIL (fdo#103166) -> PASS +2
igt@perf_pmu@rc6-runtime-pm:
shard-apl: FAIL (fdo#105010) -> PASS
Warnings
igt@kms_busy@extended-modeset-hang-newfb-render-b:
shard-apl: INCOMPLETE (fdo#103927) -> DMESG-WARN (fdo#107956)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
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#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#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
fdo#106538 https://bugs.fr
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_set_tiling_vs_pwrite: Skip on unknown swizzling
On 11/10/2018 13:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-11 13:42:31)
On 11/10/2018 13:34, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-11 13:30:27)
From: Tvrtko Ursulin
Same as in commit 78071c2fa53d ("igt/gem_tiled_partial_pwrite_pread: Check
for known swizzling"), to be able to compare the bo against the test
pattern we need to skip the test if the swizzling is not compatible.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102575
Cc: Chris Wilson
---
Eeek confidence level low - is this correct?
Actually this is a slightly more subtle problem,
https://patchwork.freedesktop.org/patch/240327/
So assuming your patch is in, this IGT cannot actually work if any
swizzling is in effect?
With the kernel patch, pwrite is a pure linear write to physical
address, not guaranteeing layout on the gpu (the gpu sees it through the
tile + swizzle combo). So set-tiling no longer affects pwrite and the
test should see identical in/out.
Yes of course..
Or without your patch, it should skip based on
known_swizzling? Or is even that not enough?
Without the patch, we would need to take swizzling into account and so
skip as we cannot know the swizzling in this case. The test illustrates
that currently we do the swizzling asymmetrically, our API is bust. The
test further illustrates that at times we cannot even know when swizzling
is required (due to L-shape eccentricities and the swizzling changing
within an object) and so the concept of handling swizzling on the API
boundary on behalf of the user is unworkable.
Sounds believable to me. So I am happy to review that patch on the
technical level, just ask you to gather some more acks. Sounds like a plan?
Is there any risk that there were no bug reports due the affected
platform being old?
Regards,
Tvrtko
___
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/perf: Add OA buffer size uAPI parameter (rev2)
== Series Details == Series: drm/i915/perf: Add OA buffer size uAPI parameter (rev2) URL : https://patchwork.freedesktop.org/series/50810/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4969 -> Patchwork_10429 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/50810/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_10429 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_pipe_crc_basic@suspend-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) +1 Possible fixes igt@gem_exec_suspend@basic-s3: fi-cfl-8109u: INCOMPLETE (fdo#107187, fdo#108126) -> PASS igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: WARN (fdo#102672) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS +1 fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126 == Participating hosts (44 -> 40) == Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-pnv-d510 == Build changes == * Linux: CI_DRM_4969 -> Patchwork_10429 CI_DRM_4969: 1121d2889e57dedacc0885deaaa9de614832e62f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10429: 7854511c4c68aaa9d99fa9deed83158cd49fa0d6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7854511c4c68 drm/i915/perf: add a parameter to control the size of OA buffer e10c7f9d8db4 drm/i915/perf: pass stream to vfuncs when possible c4fba7f16af5 drm/i915/perf: remove redundant oa buffer initialization == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10429/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Avoid a full port detection in the first eDP short pulse
On Wed, Oct 10, 2018 at 05:41:23PM -0700, José Roberto de Souza wrote:
> Some eDP panels do not set a valid sink count value and even for the
> ones that sets is should always be one for eDP, that is why it is not
> cached in intel_edp_init_dpcd().
>
> But intel_dp_short_pulse() compares the old count with the read one
> if there is a mistmatch a full port detection will be executed, what
> was happening in the first short pulse interruption of eDP panels
> that sets sink count.
>
> Instead of just skip the compasison for eDP panels, lets not read
> the sink count at all for eDP.
>
> v2: the previous version of this patch was caching the sink count
> in intel_edp_init_dpcd() but I was pointed out by Ville a patch that
> handled a case of a eDP panel that do not set sink count
>
> Cc: Ville Syrjälä
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/intel_dp.c | 44 +++--
> 1 file changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 13ff89be6ad6..1826d491efd7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4034,8 +4034,6 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> static bool
> intel_dp_get_dpcd(struct intel_dp *intel_dp)
> {
> - u8 sink_count;
> -
> if (!intel_dp_read_dpcd(intel_dp))
> return false;
>
> @@ -4045,25 +4043,35 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> intel_dp_set_common_rates(intel_dp);
> }
>
> - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &sink_count) <= 0)
> - return false;
> -
> /*
> - * Sink count can change between short pulse hpd hence
> - * a member variable in intel_dp will track any changes
> - * between short pulse interrupts.
> + * Some eDP panels do not set a valid value for sink count, that is why
> + * it don't care about read it here and in intel_edp_init_dpcd().
Can't quite parse that.
"Some eDP panels do not set a valid value
for sink count, so we ignore it."
or something like that perhaps.
>*/
> - intel_dp->sink_count = DP_GET_SINK_COUNT(sink_count);
> + if (!intel_dp_is_edp(intel_dp)) {
> + u8 count;
> + ssize_t r;
>
> - /*
> - * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> - * a dongle is present but no display. Unless we require to know
> - * if a dongle is present or not, we don't need to update
> - * downstream port information. So, an early return here saves
> - * time from performing other operations which are not required.
> - */
> - if (!intel_dp_is_edp(intel_dp) && !intel_dp->sink_count)
> - return false;
> + r = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &count);
> + if (r < 1)
> + return false;
My earlier suggestion was that we should keep reading this
anyway because some cts maybe required it. Would at least
avoid mixing in two functional changes into once patch.
> +
> + /*
> + * Sink count can change between short pulse hpd hence
> + * a member variable in intel_dp will track any changes
> + * between short pulse interrupts.
> + */
> + intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> +
> + /*
> + * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> + * a dongle is present but no display. Unless we require to know
> + * if a dongle is present or not, we don't need to update
> + * downstream port information. So, an early return here saves
> + * time from performing other operations which are not required.
> + */
> + if (!intel_dp->sink_count)
> + return false;
> + }
>
> if (!drm_dp_is_branch(intel_dp->dpcd))
> return true; /* native DP sink */
> --
> 2.19.1
--
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: failure for series starting with [1/2] drm/i915: Fix i915_driver_init_mmio error path
== Series Details == Series: series starting with [1/2] drm/i915: Fix i915_driver_init_mmio error path URL : https://patchwork.freedesktop.org/series/50868/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4969 -> Patchwork_10430 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10430 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10430, 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/50868/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10430: === IGT changes === Possible regressions igt@drv_selftest@live_requests: fi-cnl-u: PASS -> INCOMPLETE == Known issues == Here are the changes found in Patchwork_10430 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_frontbuffer_tracking@basic: fi-byt-clapper: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191) Possible fixes igt@gem_exec_suspend@basic-s3: fi-cfl-8109u: INCOMPLETE (fdo#108126, fdo#107187) -> PASS igt@kms_chamelium@dp-edid-read: fi-kbl-7500u: WARN (fdo#102672) -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107187 https://bugs.freedesktop.org/show_bug.cgi?id=107187 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126 == Participating hosts (44 -> 41) == Missing(3): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan == Build changes == * Linux: CI_DRM_4969 -> Patchwork_10430 CI_DRM_4969: 1121d2889e57dedacc0885deaaa9de614832e62f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4673: 54cb1aeb4e50dea9f3abae632e317875d147c4ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10430: 4c8f2e1cce02cc4dfe052b971ed37dc8e3114040 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4c8f2e1cce02 drm/i915: Inject load failure inside intel_engines_init_mmio bcd2f973c9b3 drm/i915: Fix i915_driver_init_mmio error path == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10430/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: Remove partial attempt to swizzle on pread/pwrite
On 23/07/2018 10:02, Chris Wilson wrote:
Our attempt to account for bit17 swizzling of pread/pwrite onto tiled
objects was flawed due to the simple fact that we do not always know the
swizzling for a particular page (due to the swizzling varying based on
location in certain unbalanced configurations). Furthermore, the
pread/pwrite paths are now unbalanced in that we are required to use the
GTT as in some cases we do not have direct CPU access to the backing
physical pages (thus some paths trying to account for the swizzle, but
others neglecting, chaos ensues).
There are no known users who do use pread/pwrite into a tiled object
(you need to manually detile anyway, so why now just use mmap and avoid
the copy?) and no user bug reports to indicate that it is being used in
the wild. As no one is hitting the buggy path, we can just remove the
buggy code.
References: fe115628d567 ("drm/i915: Implement pwrite without struct-mutex")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 191 +---
1 file changed, 30 insertions(+), 161 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8b52cb768a67..73a69352e0d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -859,58 +859,6 @@ flush_write_domain(struct drm_i915_gem_object *obj,
unsigned int flush_domains)
obj->write_domain = 0;
}
-static inline int
-__copy_to_user_swizzled(char __user *cpu_vaddr,
- const char *gpu_vaddr, int gpu_offset,
- int length)
-{
- int ret, cpu_offset = 0;
-
- while (length > 0) {
- int cacheline_end = ALIGN(gpu_offset + 1, 64);
- int this_length = min(cacheline_end - gpu_offset, length);
- int swizzled_gpu_offset = gpu_offset ^ 64;
-
- ret = __copy_to_user(cpu_vaddr + cpu_offset,
-gpu_vaddr + swizzled_gpu_offset,
-this_length);
- if (ret)
- return ret + length;
-
- cpu_offset += this_length;
- gpu_offset += this_length;
- length -= this_length;
- }
-
- return 0;
-}
-
-static inline int
-__copy_from_user_swizzled(char *gpu_vaddr, int gpu_offset,
- const char __user *cpu_vaddr,
- int length)
-{
- int ret, cpu_offset = 0;
-
- while (length > 0) {
- int cacheline_end = ALIGN(gpu_offset + 1, 64);
- int this_length = min(cacheline_end - gpu_offset, length);
- int swizzled_gpu_offset = gpu_offset ^ 64;
-
- ret = __copy_from_user(gpu_vaddr + swizzled_gpu_offset,
- cpu_vaddr + cpu_offset,
- this_length);
- if (ret)
- return ret + length;
-
- cpu_offset += this_length;
- gpu_offset += this_length;
- length -= this_length;
- }
-
- return 0;
-}
-
/*
* Pins the specified object's pages and synchronizes the object with
* GPU accesses. Sets needs_clflush to non-zero if the caller should
@@ -1030,72 +978,29 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
return ret;
}
-static void
-shmem_clflush_swizzled_range(char *addr, unsigned long length,
-bool swizzled)
-{
- if (unlikely(swizzled)) {
- unsigned long start = (unsigned long) addr;
- unsigned long end = (unsigned long) addr + length;
-
- /* For swizzling simply ensure that we always flush both
-* channels. Lame, but simple and it works. Swizzled
-* pwrite/pread is far from a hotpath - current userspace
-* doesn't use it at all. */
- start = round_down(start, 128);
- end = round_up(end, 128);
-
- drm_clflush_virt_range((void *)start, end - start);
- } else {
- drm_clflush_virt_range(addr, length);
- }
-
-}
-
-/* Only difference to the fast-path function is that this can handle bit17
- * and uses non-atomic copy and kmap functions. */
static int
-shmem_pread_slow(struct page *page, int offset, int length,
-char __user *user_data,
-bool page_do_bit17_swizzling, bool needs_clflush)
+shmem_pread(struct page *page, int offset, int len, char __user *user_data,
+ bool needs_clflush)
{
char *vaddr;
int ret;
- vaddr = kmap(page);
- if (needs_clflush)
- shmem_clflush_swizzled_range(vaddr + offset, length,
-page_do_bit17_swizzling);
-
- if (page_do_bit17_swizzling)
- ret = __copy_to_user_swizzled(user_data, vaddr, offset, l
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Convert _print_param to a macro (rev2)
== Series Details ==
Series: drm/i915: Convert _print_param to a macro (rev2)
URL : https://patchwork.freedesktop.org/series/50789/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4968_full -> Patchwork_10422_full =
== Summary - SUCCESS ==
No regressions found.
== Known issues ==
Here are the changes found in Patchwork_10422_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_exec_schedule@pi-ringfull-bsd:
shard-skl: NOTRUN -> FAIL (fdo#103158) +2
igt@gem_mmap@bad-object:
shard-apl: PASS -> DMESG-WARN (fdo#105602, fdo#103558)
igt@kms_addfb_basic@bo-too-small-due-to-tiling:
shard-snb: NOTRUN -> DMESG-WARN (fdo#107469) +1
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
shard-snb: NOTRUN -> DMESG-WARN (fdo#107956) +1
igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
shard-glk: PASS -> DMESG-WARN (fdo#106538, fdo#105763)
igt@kms_cursor_legacy@pipe-c-forked-move:
shard-apl: PASS -> INCOMPLETE (fdo#103927)
igt@kms_flip@flip-vs-expired-vblank:
shard-glk: PASS -> FAIL (fdo#105363, fdo#102887)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
shard-glk: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-cpu:
shard-glk: PASS -> DMESG-FAIL (fdo#106538)
igt@kms_frontbuffer_tracking@fbcpsr-suspend:
shard-skl: PASS -> INCOMPLETE (fdo#107773, fdo#104108)
igt@kms_pipe_crc_basic@read-crc-pipe-c:
shard-skl: NOTRUN -> FAIL (fdo#107362) +1
igt@kms_plane@pixel-format-pipe-c-planes:
shard-skl: NOTRUN -> DMESG-FAIL (fdo#103166, fdo#106885)
{igt@kms_plane_alpha_blend@pipe-a-alpha-7efc}:
shard-skl: NOTRUN -> FAIL (fdo#108145) +3
{igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb}:
shard-kbl: NOTRUN -> FAIL (fdo#108145)
{igt@kms_plane_alpha_blend@pipe-c-alpha-7efc}:
shard-skl: NOTRUN -> FAIL (fdo#108146)
{igt@kms_plane_alpha_blend@pipe-c-coverage-7efc}:
shard-apl: NOTRUN -> FAIL (fdo#108146)
igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
shard-skl: NOTRUN -> FAIL (fdo#103166)
igt@kms_setmode@basic:
shard-kbl: PASS -> FAIL (fdo#99912)
igt@kms_sysfs_edid_timing:
shard-skl: NOTRUN -> FAIL (fdo#100047)
igt@kms_vblank@pipe-b-wait-forked:
shard-snb: NOTRUN -> INCOMPLETE (fdo#105411)
igt@perf@blocking:
shard-hsw: PASS -> FAIL (fdo#102252)
igt@perf_pmu@rc6-runtime-pm:
shard-glk: PASS -> FAIL (fdo#105010)
igt@pm_rpm@sysfs-read:
shard-skl: PASS -> INCOMPLETE (fdo#107807)
Possible fixes
igt@drv_hangman@error-state-capture-render:
shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS
igt@gem_userptr_blits@readonly-unsync:
shard-kbl: INCOMPLETE (fdo#103665) -> PASS
igt@kms_busy@extended-pageflip-hang-newfb-render-a:
shard-glk: DMESG-WARN (fdo#107956) -> PASS
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
shard-kbl: DMESG-WARN (fdo#107956) -> PASS
igt@kms_color@pipe-a-ctm-max:
shard-skl: FAIL (fdo#108147) -> PASS
igt@kms_cursor_crc@cursor-256x256-random:
shard-apl: FAIL (fdo#103232) -> PASS +2
igt@kms_flip@flip-vs-expired-vblank:
shard-kbl: FAIL (fdo#105363, fdo#102887) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
shard-apl: FAIL (fdo#103167) -> PASS +2
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
shard-glk: FAIL (fdo#103167) -> PASS +1
igt@kms_frontbuffer_tracking@psr-farfromfence:
shard-skl: FAIL (fdo#103167) -> PASS
igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
shard-skl: INCOMPLETE (fdo#107773, fdo#104108) -> PASS +1
{igt@kms_plane_alpha_blend@pipe-a-coverage-7efc}:
shard-skl: FAIL (fdo#108145) -> PASS
igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
shard-glk: FAIL (fdo#103166) -> PASS
igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
shard-apl: FAIL (fdo#103166) -> PASS
igt@perf_pmu@rc6-runtime-pm:
shard-apl: FAIL (fdo#105010) -> PASS
Warnings
igt@kms_busy@extended-modeset-hang-newfb-render-b:
shard-apl: INCOMPLETE (fdo#103927) -> DMESG-WARN (fdo#107956)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, o
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Disable shrinker across mmap-exhaustion
Chris Wilson writes:
> For mmap-exhaustion, we deliberately put the system under a large amount
> of pressure to ensure that we are able to reap mmap-offsets from dead
> objects. If background activity does that reaping for us, that defeats
> the purpose of the test and in some cases will fail our sanity checks
> (because of the fake activity we use to prevent the idle worker).
>
mark_obj_busy will both pin and mark the object as active. And we
have disabled the retire worker. So how can an active object
end up being purged?
-Mika
> Fixes: 932cac10c8fb ("drm/i915/selftests: Prevent background reaping of acti
> ve objects")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Matthew Auld
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_object.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
> index 6d3516d5bff9..c3999dd2021e 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
> @@ -501,6 +501,8 @@ static bool assert_mmap_offset(struct drm_i915_private
> *i915,
>
> static void disable_retire_worker(struct drm_i915_private *i915)
> {
> + i915_gem_shrinker_unregister(i915);
> +
> mutex_lock(&i915->drm.struct_mutex);
> if (!i915->gt.active_requests++) {
> intel_runtime_pm_get(i915);
> @@ -613,6 +615,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
> else
> queue_delayed_work(i915->wq, &i915->gt.idle_work, 0);
> mutex_unlock(&i915->drm.struct_mutex);
> + i915_gem_shrinker_register(i915);
> return err;
> err_obj:
> i915_gem_object_put(obj);
> --
> 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: Remove partial attempt to swizzle on pread/pwrite
Quoting Tvrtko Ursulin (2018-10-11 14:38:41)
>
> On 23/07/2018 10:02, Chris Wilson wrote:
> > Our attempt to account for bit17 swizzling of pread/pwrite onto tiled
> > objects was flawed due to the simple fact that we do not always know the
> > swizzling for a particular page (due to the swizzling varying based on
> > location in certain unbalanced configurations). Furthermore, the
> > pread/pwrite paths are now unbalanced in that we are required to use the
> > GTT as in some cases we do not have direct CPU access to the backing
> > physical pages (thus some paths trying to account for the swizzle, but
> > others neglecting, chaos ensues).
> >
> > There are no known users who do use pread/pwrite into a tiled object
> > (you need to manually detile anyway, so why now just use mmap and avoid
> > the copy?) and no user bug reports to indicate that it is being used in
> > the wild. As no one is hitting the buggy path, we can just remove the
> > buggy code.
> >
> > References: fe115628d567 ("drm/i915: Implement pwrite without struct-mutex")
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 191 +---
> > 1 file changed, 30 insertions(+), 161 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 8b52cb768a67..73a69352e0d4 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -859,58 +859,6 @@ flush_write_domain(struct drm_i915_gem_object *obj,
> > unsigned int flush_domains)
> > obj->write_domain = 0;
> > }
> >
> > -static inline int
> > -__copy_to_user_swizzled(char __user *cpu_vaddr,
> > - const char *gpu_vaddr, int gpu_offset,
> > - int length)
> > -{
> > - int ret, cpu_offset = 0;
> > -
> > - while (length > 0) {
> > - int cacheline_end = ALIGN(gpu_offset + 1, 64);
> > - int this_length = min(cacheline_end - gpu_offset, length);
> > - int swizzled_gpu_offset = gpu_offset ^ 64;
> > -
> > - ret = __copy_to_user(cpu_vaddr + cpu_offset,
> > - gpu_vaddr + swizzled_gpu_offset,
> > - this_length);
> > - if (ret)
> > - return ret + length;
> > -
> > - cpu_offset += this_length;
> > - gpu_offset += this_length;
> > - length -= this_length;
> > - }
> > -
> > - return 0;
> > -}
> > -
> > -static inline int
> > -__copy_from_user_swizzled(char *gpu_vaddr, int gpu_offset,
> > - const char __user *cpu_vaddr,
> > - int length)
> > -{
> > - int ret, cpu_offset = 0;
> > -
> > - while (length > 0) {
> > - int cacheline_end = ALIGN(gpu_offset + 1, 64);
> > - int this_length = min(cacheline_end - gpu_offset, length);
> > - int swizzled_gpu_offset = gpu_offset ^ 64;
> > -
> > - ret = __copy_from_user(gpu_vaddr + swizzled_gpu_offset,
> > -cpu_vaddr + cpu_offset,
> > -this_length);
> > - if (ret)
> > - return ret + length;
> > -
> > - cpu_offset += this_length;
> > - gpu_offset += this_length;
> > - length -= this_length;
> > - }
> > -
> > - return 0;
> > -}
> > -
> > /*
> >* Pins the specified object's pages and synchronizes the object with
> >* GPU accesses. Sets needs_clflush to non-zero if the caller should
> > @@ -1030,72 +978,29 @@ int i915_gem_obj_prepare_shmem_write(struct
> > drm_i915_gem_object *obj,
> > return ret;
> > }
> >
> > -static void
> > -shmem_clflush_swizzled_range(char *addr, unsigned long length,
> > - bool swizzled)
> > -{
> > - if (unlikely(swizzled)) {
> > - unsigned long start = (unsigned long) addr;
> > - unsigned long end = (unsigned long) addr + length;
> > -
> > - /* For swizzling simply ensure that we always flush both
> > - * channels. Lame, but simple and it works. Swizzled
> > - * pwrite/pread is far from a hotpath - current userspace
> > - * doesn't use it at all. */
> > - start = round_down(start, 128);
> > - end = round_up(end, 128);
> > -
> > - drm_clflush_virt_range((void *)start, end - start);
> > - } else {
> > - drm_clflush_virt_range(addr, length);
> > - }
> > -
> > -}
> > -
> > -/* Only difference to the fast-path function is that this can handle bit17
> > - * and uses non-atomic copy and kmap functions. */
> > static int
> > -shmem_pread_slow(struct page *page, int offset, int length,
> > - char __user *user_data,
> > - bool page_do_bit17_swizzling, bool needs_clflush)
> > +shmem_pread(struct page *page
Re: [Intel-gfx] [PATCH 4/4] drm/i915/icl: Handle GT interrupts after enabling master
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-10-02 15:05:52)
>> Don't keep master disabled while we handle the current
>> interrupts. This should help a little on latency of
>> generating the next interrupt.
>>
>> Suggested-by: Chris Wilson
>> Cc: Chris Wilson
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 5d1f53723388..9d8d5fb68c84 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -3163,9 +3163,6 @@ static irqreturn_t gen11_irq_handler(int irq, void
>> *arg)
>> return IRQ_NONE;
>> }
>>
>> - /* Find, clear, then process each source of interrupt. */
>> - gen11_gt_irq_handler(i915, master_ctl);
>> -
>> /* IRQs are synced during runtime_suspend, we don't require a
>> wakeref */
>> if (master_ctl & GEN11_DISPLAY_IRQ) {
>> const u32 disp_ctl = raw_reg_read(regs,
>> GEN11_DISPLAY_INT_CTL);
>> @@ -3183,6 +3180,7 @@ static irqreturn_t gen11_irq_handler(int irq, void
>> *arg)
>>
>> gen11_master_intr_enable(regs);
>>
>> + gen11_gt_irq_handler(i915, master_ctl);
>
> Are we not still acking GT_INTR_DW at this point?
We are.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Disable shrinker across mmap-exhaustion
Quoting Mika Kuoppala (2018-10-11 14:56:42) > Chris Wilson writes: > > > For mmap-exhaustion, we deliberately put the system under a large amount > > of pressure to ensure that we are able to reap mmap-offsets from dead > > objects. If background activity does that reaping for us, that defeats > > the purpose of the test and in some cases will fail our sanity checks > > (because of the fake activity we use to prevent the idle worker). > > > > mark_obj_busy will both pin and mark the object as active. And we > have disabled the retire worker. So how can an active object > end up being purged? The shrinker. <3> [390.421056] i915_gem_wait_for_idle:3426 GEM_BUG_ON(i915->gt.active_requests) <4> [390.421904] [ cut here ] <2> [390.421907] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3426! <4> [390.421921] invalid opcode: [#1] PREEMPT SMP PTI <4> [390.421927] CPU: 1 PID: 51 Comm: kswapd0 Tainted: G U 4.19.0-rc7-CI-Trybot_3063+ #1 <4> [390.421930] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 <4> [390.422030] RIP: 0010:i915_gem_wait_for_idle.part.25+0x205/0x210 [i915] <4> [390.422034] Code: 3a 3b 6d e0 48 8b 35 aa b8 1d 00 49 c7 c0 0a 9a b4 a0 b9 62 0d 00 00 48 c7 c2 90 fc b2 a0 48 c7 c7 00 65 a2 a0 e8 8b ca 73 e0 <0f> 0b 66 0f 1f 84 00 00 00 00 00 49 89 fa 31 c0 48 89 f7 b9 14 00 <4> [390.422037] RSP: 0018:c93a7b78 EFLAGS: 00010286 <4> [390.422041] RAX: 000e RBX: 000a RCX: <4> [390.422043] RDX: 0001 RSI: 0008 RDI: 88017b1efa38 <4> [390.422046] RBP: 88006c53b1d0 R08: 001b1b25 R09: 88017b344000 <4> [390.422048] R10: R11: 88017b1efa38 R12: 005ac6b50a70 <4> [390.422051] R13: 88006c53 R14: 88006c53b270 R15: 0002 <4> [390.422054] FS: () GS:88017ba8() knlGS: <4> [390.422057] CS: 0010 DS: ES: CR0: 80050033 <4> [390.422059] CR2: 7f5016f07228 CR3: 0521 CR4: 00340ee0 <4> [390.422061] Call Trace: <4> [390.422124] i915_gem_shrink+0x486/0x5b0 [i915] <4> [390.422136] ? shrink_node+0xe2/0x450 <4> [390.422197] ? i915_gem_shrinker_scan+0x10e/0x130 [i915] <4> [390.422256] i915_gem_shrinker_scan+0x10e/0x130 [i915] <4> [390.422263] do_shrink_slab+0x13e/0x3d0 <4> [390.422269] shrink_slab+0x228/0x2c0 <4> [390.422275] shrink_node+0xe2/0x450 <4> [390.422281] kswapd+0x2f8/0x8f0 <4> [390.422289] ? mem_cgroup_shrink_node+0x290/0x290 <4> [390.422294] kthread+0x119/0x130 <4> [390.422298] ? kthread_park+0x80/0x80 <4> [390.422305] ret_from_fork+0x3a/0x50 -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove partial attempt to swizzle on pread/pwrite
On 11/10/2018 15:30, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-11 14:38:41)
On 23/07/2018 10:02, Chris Wilson wrote:
Our attempt to account for bit17 swizzling of pread/pwrite onto tiled
objects was flawed due to the simple fact that we do not always know the
swizzling for a particular page (due to the swizzling varying based on
location in certain unbalanced configurations). Furthermore, the
pread/pwrite paths are now unbalanced in that we are required to use the
GTT as in some cases we do not have direct CPU access to the backing
physical pages (thus some paths trying to account for the swizzle, but
others neglecting, chaos ensues).
There are no known users who do use pread/pwrite into a tiled object
(you need to manually detile anyway, so why now just use mmap and avoid
the copy?) and no user bug reports to indicate that it is being used in
the wild. As no one is hitting the buggy path, we can just remove the
buggy code.
References: fe115628d567 ("drm/i915: Implement pwrite without struct-mutex")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 191 +---
1 file changed, 30 insertions(+), 161 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8b52cb768a67..73a69352e0d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -859,58 +859,6 @@ flush_write_domain(struct drm_i915_gem_object *obj,
unsigned int flush_domains)
obj->write_domain = 0;
}
-static inline int
-__copy_to_user_swizzled(char __user *cpu_vaddr,
- const char *gpu_vaddr, int gpu_offset,
- int length)
-{
- int ret, cpu_offset = 0;
-
- while (length > 0) {
- int cacheline_end = ALIGN(gpu_offset + 1, 64);
- int this_length = min(cacheline_end - gpu_offset, length);
- int swizzled_gpu_offset = gpu_offset ^ 64;
-
- ret = __copy_to_user(cpu_vaddr + cpu_offset,
- gpu_vaddr + swizzled_gpu_offset,
- this_length);
- if (ret)
- return ret + length;
-
- cpu_offset += this_length;
- gpu_offset += this_length;
- length -= this_length;
- }
-
- return 0;
-}
-
-static inline int
-__copy_from_user_swizzled(char *gpu_vaddr, int gpu_offset,
- const char __user *cpu_vaddr,
- int length)
-{
- int ret, cpu_offset = 0;
-
- while (length > 0) {
- int cacheline_end = ALIGN(gpu_offset + 1, 64);
- int this_length = min(cacheline_end - gpu_offset, length);
- int swizzled_gpu_offset = gpu_offset ^ 64;
-
- ret = __copy_from_user(gpu_vaddr + swizzled_gpu_offset,
-cpu_vaddr + cpu_offset,
-this_length);
- if (ret)
- return ret + length;
-
- cpu_offset += this_length;
- gpu_offset += this_length;
- length -= this_length;
- }
-
- return 0;
-}
-
/*
* Pins the specified object's pages and synchronizes the object with
* GPU accesses. Sets needs_clflush to non-zero if the caller should
@@ -1030,72 +978,29 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
return ret;
}
-static void
-shmem_clflush_swizzled_range(char *addr, unsigned long length,
- bool swizzled)
-{
- if (unlikely(swizzled)) {
- unsigned long start = (unsigned long) addr;
- unsigned long end = (unsigned long) addr + length;
-
- /* For swizzling simply ensure that we always flush both
- * channels. Lame, but simple and it works. Swizzled
- * pwrite/pread is far from a hotpath - current userspace
- * doesn't use it at all. */
- start = round_down(start, 128);
- end = round_up(end, 128);
-
- drm_clflush_virt_range((void *)start, end - start);
- } else {
- drm_clflush_virt_range(addr, length);
- }
-
-}
-
-/* Only difference to the fast-path function is that this can handle bit17
- * and uses non-atomic copy and kmap functions. */
static int
-shmem_pread_slow(struct page *page, int offset, int length,
- char __user *user_data,
- bool page_do_bit17_swizzling, bool needs_clflush)
+shmem_pread(struct page *page, int offset, int len, char __user *user_data,
+ bool needs_clflush)
{
char *vaddr;
int ret;
- vaddr = kmap(page);
- if (needs_clflush)
- shmem_clflush_swizzled_range(vaddr + offset, length,
- page_do_bit17_swizzling);
-
- if (page_do_bit17_swizzling)
- ret = __copy_to_user_swizzled(user_data, vaddr, offset, length);
-
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Disable shrinker across mmap-exhaustion
Chris Wilson writes: > Quoting Mika Kuoppala (2018-10-11 14:56:42) >> Chris Wilson writes: >> >> > For mmap-exhaustion, we deliberately put the system under a large amount >> > of pressure to ensure that we are able to reap mmap-offsets from dead >> > objects. If background activity does that reaping for us, that defeats >> > the purpose of the test and in some cases will fail our sanity checks >> > (because of the fake activity we use to prevent the idle worker). >> > >> >> mark_obj_busy will both pin and mark the object as active. And we >> have disabled the retire worker. So how can an active object >> end up being purged? > > The shrinker. Got it, thanks. Now the commit message makes sense. Reviewed-by: Mika Kuoppala > > <3> [390.421056] i915_gem_wait_for_idle:3426 > GEM_BUG_ON(i915->gt.active_requests) > <4> [390.421904] [ cut here ] > <2> [390.421907] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3426! > <4> [390.421921] invalid opcode: [#1] PREEMPT SMP PTI > <4> [390.421927] CPU: 1 PID: 51 Comm: kswapd0 Tainted: G U > 4.19.0-rc7-CI-Trybot_3063+ #1 > <4> [390.421930] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), > BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 > <4> [390.422030] RIP: 0010:i915_gem_wait_for_idle.part.25+0x205/0x210 [i915] > <4> [390.422034] Code: 3a 3b 6d e0 48 8b 35 aa b8 1d 00 49 c7 c0 0a 9a b4 a0 > b9 62 0d 00 00 48 c7 c2 90 fc b2 a0 48 c7 c7 00 65 a2 a0 e8 8b ca 73 e0 <0f> > 0b 66 0f 1f 84 00 00 00 00 00 49 89 fa 31 c0 48 89 f7 b9 14 00 > <4> [390.422037] RSP: 0018:c93a7b78 EFLAGS: 00010286 > <4> [390.422041] RAX: 000e RBX: 000a RCX: > > <4> [390.422043] RDX: 0001 RSI: 0008 RDI: > 88017b1efa38 > <4> [390.422046] RBP: 88006c53b1d0 R08: 001b1b25 R09: > 88017b344000 > <4> [390.422048] R10: R11: 88017b1efa38 R12: > 005ac6b50a70 > <4> [390.422051] R13: 88006c53 R14: 88006c53b270 R15: > 0002 > <4> [390.422054] FS: () GS:88017ba8() > knlGS: > <4> [390.422057] CS: 0010 DS: ES: CR0: 80050033 > <4> [390.422059] CR2: 7f5016f07228 CR3: 0521 CR4: > 00340ee0 > <4> [390.422061] Call Trace: > <4> [390.422124] i915_gem_shrink+0x486/0x5b0 [i915] > <4> [390.422136] ? shrink_node+0xe2/0x450 > <4> [390.422197] ? i915_gem_shrinker_scan+0x10e/0x130 [i915] > <4> [390.422256] i915_gem_shrinker_scan+0x10e/0x130 [i915] > <4> [390.422263] do_shrink_slab+0x13e/0x3d0 > <4> [390.422269] shrink_slab+0x228/0x2c0 > <4> [390.422275] shrink_node+0xe2/0x450 > <4> [390.422281] kswapd+0x2f8/0x8f0 > <4> [390.422289] ? mem_cgroup_shrink_node+0x290/0x290 > <4> [390.422294] kthread+0x119/0x130 > <4> [390.422298] ? kthread_park+0x80/0x80 > <4> [390.422305] ret_from_fork+0x3a/0x50 > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/6] lib: Don't call igt_require_fb_modifiers() when no modifier
On Wed, Oct 10, 2018 at 05:21:02PM -0700, Deepak Rawat wrote: > vmwgfx doesn't support fb modifier so skip igt_require_fb_modifiers() > when modifier are not passed. > > Signed-off-by: Deepak Rawat > --- > lib/ioctl_wrappers.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > index 0929c43f..3a11cb6e 100644 > --- a/lib/ioctl_wrappers.c > +++ b/lib/ioctl_wrappers.c > @@ -1678,7 +1678,10 @@ int __kms_addfb(int fd, uint32_t handle, > struct drm_mode_fb_cmd2 f; > int ret, i; > > - igt_require_fb_modifiers(fd); > + if (modifier) > + igt_require_fb_modifiers(fd); > + else > + flags &= ~DRM_MODE_FB_MODIFIERS; This would theoretically change the behviour for i915 at least. Without the modifiers flag the kernel will pick the modifier for us based on the bo tiling, which in theory might not be what we wanted. But at least igt_fb should be fine with that. Maybe it would be better to just not pass the flags from the caller at all, and instead have __kms_addfb() check if the driver has modifiers or not and set the flag based on that? > > memset(&f, 0, sizeof(f)); > > -- > 2.17.1 > > ___ > igt-dev mailing list > igt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/igt-dev -- 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 4/4] drm/i915/icl: Handle GT interrupts after enabling master
Quoting Mika Kuoppala (2018-10-11 15:19:24)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-10-02 15:05:52)
> >> Don't keep master disabled while we handle the current
> >> interrupts. This should help a little on latency of
> >> generating the next interrupt.
> >>
> >> Suggested-by: Chris Wilson
> >> Cc: Chris Wilson
> >> Signed-off-by: Mika Kuoppala
> >> ---
> >> drivers/gpu/drm/i915/i915_irq.c | 4 +---
> >> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 5d1f53723388..9d8d5fb68c84 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -3163,9 +3163,6 @@ static irqreturn_t gen11_irq_handler(int irq, void
> >> *arg)
> >> return IRQ_NONE;
> >> }
> >>
> >> - /* Find, clear, then process each source of interrupt. */
> >> - gen11_gt_irq_handler(i915, master_ctl);
> >> -
> >> /* IRQs are synced during runtime_suspend, we don't require a
> >> wakeref */
> >> if (master_ctl & GEN11_DISPLAY_IRQ) {
> >> const u32 disp_ctl = raw_reg_read(regs,
> >> GEN11_DISPLAY_INT_CTL);
> >> @@ -3183,6 +3180,7 @@ static irqreturn_t gen11_irq_handler(int irq, void
> >> *arg)
> >>
> >> gen11_master_intr_enable(regs);
> >>
> >> + gen11_gt_irq_handler(i915, master_ctl);
> >
> > Are we not still acking GT_INTR_DW at this point?
>
> We are.
Then we re-enable MASTER before we ack the in the individual GT_IIR, and
by the logic before, that means MASTER still has the GT bits asserted
(as we said they are not cleared until we ack the individual GT_IIR).
Doesn't that mean that the interrupt will be raised again immediately?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/6] lib/igt_fb: Check for cairo surface success
On Wed, Oct 10, 2018 at 05:21:01PM -0700, Deepak Rawat wrote: > For vmwgfx cairo surface creation fails due to stride mismatch, add a > igt_require_f() for surface. Hmm. What kind of pixel format are you using? It seems to me cairo should be happy with just a 4 byte aligned stride. How bad would it be to change vmw_dumb_create() to give you that? Having working cairo stuff should make igt_fb much more useful for you in general. Alternative would to not use dumb buffers I suppose, but then we'd need to make sure the igt_fb size calculations are OK for vmwgfx. Currently igt_fb assumes Intel hw in the sense that linear buffers will get a 64byte aligned stride. > > v2: Check for surface creation failure. > > Signed-off-by: Deepak Rawat > --- > lib/igt_fb.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/lib/igt_fb.c b/lib/igt_fb.c > index 335ece69..1bb6d324 100644 > --- a/lib/igt_fb.c > +++ b/lib/igt_fb.c > @@ -1433,6 +1433,10 @@ static void create_cairo_surface__gtt(int fd, struct > igt_fb *fb) > cairo_image_surface_create_for_data(ptr, > > drm_format_to_cairo(fb->drm_format), > fb->width, fb->height, > fb->strides[0]); > + igt_require_f(cairo_surface_status(fb->cairo_surface) == > CAIRO_STATUS_SUCCESS, > + "Unable to create a cairo surface: %s\n", > + > cairo_status_to_string(cairo_surface_status(fb->cairo_surface))); > + > fb->domain = I915_GEM_DOMAIN_GTT; > > cairo_surface_set_user_data(fb->cairo_surface, > -- > 2.17.1 > > ___ > igt-dev mailing list > igt-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/igt-dev -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
>
> On Wed, Oct 10, 2018 at 05:20:59PM -0700, Deepak Rawat wrote:
> > Add DRIVER_VMWGFX to represent vmwgfx device for running igt tests.
> >
> > v2: Don't remove second virtio_gpu
> >
> > Signed-off-by: Deepak Rawat
> > ---
> > lib/drmtest.c | 8
> > lib/drmtest.h | 3 +++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > index fee9d33a..9d013a00 100644
> > --- a/lib/drmtest.c
> > +++ b/lib/drmtest.c
> > @@ -105,6 +105,11 @@ bool is_i915_device(int fd)
> > return __is_device(fd, "i915");
> > }
> >
> > +bool is_vmwgfx_device(int fd)
> > +{
> > + return __is_device(fd, "vmwg");
> > +}
> > +
> > static bool has_known_intel_chipset(int fd)
> > {
> > struct drm_i915_getparam gp;
> > @@ -206,6 +211,7 @@ static const struct module {
> > { DRIVER_VGEM, "vgem" },
> > { DRIVER_VIRTIO, "virtio-gpu" },
> > { DRIVER_VIRTIO, "virtio_gpu" },
> > + { DRIVER_VMWGFX, "vmwgfx" },
> > {}
> > };
> >
> > @@ -348,6 +354,8 @@ static const char *chipset_to_str(int chipset)
> > return "virtio";
> > case DRIVER_AMDGPU:
> > return "amdgpu";
> > + case DRIVER_VMWGFX:
> > + return "vmwgfx";
> > case DRIVER_ANY:
> > return "any";
> > default:
> > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > index 949865ee..0213fb51 100644
> > --- a/lib/drmtest.h
> > +++ b/lib/drmtest.h
> > @@ -43,6 +43,7 @@
> > #define DRIVER_VGEM(1 << 2)
> > #define DRIVER_VIRTIO (1 << 3)
> > #define DRIVER_AMDGPU (1 << 4)
> > +#define DRIVER_VMWGFX (1 << 5)
>
> This seems not needed? For pure generic kms tests I think it'd be great if
> we don't have to sprinkle driver-specific checks all over. Which you seem
> to achive in your series here.
>
> So not clear why this here is needed?
> -Daniel
Hi Daniel,
Thanks for the review. You are right for kms tests having vmwgfx driver type
is not needed but I added vmwgfx device type because I plan to add more
vmwgfx test cases, and since vmwgfx buffer allocation is private ioctl
having a separate device type might be needed.
I can drop this until I have some vmwgfx specific test cases.
>
> > /*
> > * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> > * with vgem as well as a supported driver, you can end up with a
> > @@ -80,6 +81,8 @@ void igt_require_intel(int fd);
> >
> > bool is_i915_device(int fd);
> >
> > +bool is_vmwgfx_device(int fd);
> > +
> > /**
> > * do_or_die:
> > * @x: command
> > --
> > 2.17.1
> >
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr
> eedesktop.org%2Fmailman%2Flistinfo%2Figt-
> dev&data=02%7C01%7Cdrawat%40vmware.com%7C5486d67be73647b1
> 1d2708d62f58307d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C6
> 36748453147406904&sdata=QcT4VTQth8GuXgjZejCsnFPDsMFbtqrUOW
> uSDr8zbG8%3D&reserved=0
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ff
> wll.ch&data=02%7C01%7Cdrawat%40vmware.com%7C5486d67be73647
> b11d2708d62f58307d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7
> C636748453147406904&sdata=4SKi8P5PeyCAUsoZh%2BsYFC%2FU2RiEx5
> qp2gPP7bPr3Bo%3D&reserved=0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/plane_damage: Integrate kernel selftest test-drm_damage_helper
> > diff --git a/tests/meson.build b/tests/meson.build > > index 697ff515..5acd7aa2 100644 > > --- a/tests/meson.build > > +++ b/tests/meson.build > > @@ -9,6 +9,7 @@ test_progs = [ > > 'debugfs_test', > > 'drm_import_export', > > 'drm_mm', > > + 'drm_plane_damage', > > For future proofing I think it'd be much better if we call this drm_kms or > similar. The individual subtest results will be all exposed, but there's a > bit a problem when we always have to upgrade both igt and the kernel at > the same time. At least with the current CI infrastructure. Do you mean drm_kms_plane_damage? IIUC this is to allow running test from run-test.sh? I suppose in that case it should be named kms_plane_damage, because all other kms test starts with kms_*. > > I'm also asking the ARM folks to type selftests for the new block_* format > description stuff, so this will come in handy real soon. > -Daniel > > > 'drm_read', > > 'drv_getparams_basic', > > 'drv_hangman', > > -- > > 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/plane_damage: Integrate kernel selftest test-drm_damage_helper
On Thu, Oct 11, 2018 at 03:23:58PM +, Deepak Singh Rawat wrote: > > > diff --git a/tests/meson.build b/tests/meson.build > > > index 697ff515..5acd7aa2 100644 > > > --- a/tests/meson.build > > > +++ b/tests/meson.build > > > @@ -9,6 +9,7 @@ test_progs = [ > > > 'debugfs_test', > > > 'drm_import_export', > > > 'drm_mm', > > > + 'drm_plane_damage', > > > > For future proofing I think it'd be much better if we call this drm_kms or > > similar. The individual subtest results will be all exposed, but there's a > > bit a problem when we always have to upgrade both igt and the kernel at > > the same time. At least with the current CI infrastructure. > > Do you mean drm_kms_plane_damage? IIUC this is to allow running test > from run-test.sh? I suppose in that case it should be named > kms_plane_damage, because all other kms test starts with kms_*. Ah yes, sticking to the kms_ prefix is a good idea. kms_selftests is what I'd recommend. For both the igt wrapper here, and the kernel module. That way it's a natural place to add all kinds of kms self tests in the future, without the need to go through the basic scaffolding steps again. Cheers, Daniel > > > > > I'm also asking the ARM folks to type selftests for the new block_* format > > description stuff, so this will come in handy real soon. > > -Daniel > > > > > 'drm_read', > > > 'drv_getparams_basic', > > > 'drv_hangman', > > > -- > > > 2.17.1 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
On Thu, Oct 11, 2018 at 03:17:01PM +, Deepak Singh Rawat wrote:
> >
> > On Wed, Oct 10, 2018 at 05:20:59PM -0700, Deepak Rawat wrote:
> > > Add DRIVER_VMWGFX to represent vmwgfx device for running igt tests.
> > >
> > > v2: Don't remove second virtio_gpu
> > >
> > > Signed-off-by: Deepak Rawat
> > > ---
> > > lib/drmtest.c | 8
> > > lib/drmtest.h | 3 +++
> > > 2 files changed, 11 insertions(+)
> > >
> > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > index fee9d33a..9d013a00 100644
> > > --- a/lib/drmtest.c
> > > +++ b/lib/drmtest.c
> > > @@ -105,6 +105,11 @@ bool is_i915_device(int fd)
> > > return __is_device(fd, "i915");
> > > }
> > >
> > > +bool is_vmwgfx_device(int fd)
> > > +{
> > > + return __is_device(fd, "vmwg");
> > > +}
> > > +
> > > static bool has_known_intel_chipset(int fd)
> > > {
> > > struct drm_i915_getparam gp;
> > > @@ -206,6 +211,7 @@ static const struct module {
> > > { DRIVER_VGEM, "vgem" },
> > > { DRIVER_VIRTIO, "virtio-gpu" },
> > > { DRIVER_VIRTIO, "virtio_gpu" },
> > > + { DRIVER_VMWGFX, "vmwgfx" },
> > > {}
> > > };
> > >
> > > @@ -348,6 +354,8 @@ static const char *chipset_to_str(int chipset)
> > > return "virtio";
> > > case DRIVER_AMDGPU:
> > > return "amdgpu";
> > > + case DRIVER_VMWGFX:
> > > + return "vmwgfx";
> > > case DRIVER_ANY:
> > > return "any";
> > > default:
> > > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > > index 949865ee..0213fb51 100644
> > > --- a/lib/drmtest.h
> > > +++ b/lib/drmtest.h
> > > @@ -43,6 +43,7 @@
> > > #define DRIVER_VGEM (1 << 2)
> > > #define DRIVER_VIRTIO(1 << 3)
> > > #define DRIVER_AMDGPU(1 << 4)
> > > +#define DRIVER_VMWGFX(1 << 5)
> >
> > This seems not needed? For pure generic kms tests I think it'd be great if
> > we don't have to sprinkle driver-specific checks all over. Which you seem
> > to achive in your series here.
> >
> > So not clear why this here is needed?
> > -Daniel
>
> Hi Daniel,
>
> Thanks for the review. You are right for kms tests having vmwgfx driver type
> is not needed but I added vmwgfx device type because I plan to add more
> vmwgfx test cases, and since vmwgfx buffer allocation is private ioctl
> having a separate device type might be needed.
Oh, this sounds awesome. And yes, for private ioctl tests vmwgfx is
obviuosly very much welcome!
> I can drop this until I have some vmwgfx specific test cases.
Sounds like a good plan to me.
-Daniel
>
> >
> > > /*
> > > * Exclude DRVER_VGEM from DRIVER_ANY since if you run on a system
> > > * with vgem as well as a supported driver, you can end up with a
> > > @@ -80,6 +81,8 @@ void igt_require_intel(int fd);
> > >
> > > bool is_i915_device(int fd);
> > >
> > > +bool is_vmwgfx_device(int fd);
> > > +
> > > /**
> > > * do_or_die:
> > > * @x: command
> > > --
> > > 2.17.1
> > >
> > > ___
> > > igt-dev mailing list
> > > igt-...@lists.freedesktop.org
> > >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr
> > eedesktop.org%2Fmailman%2Flistinfo%2Figt-
> > dev&data=02%7C01%7Cdrawat%40vmware.com%7C5486d67be73647b1
> > 1d2708d62f58307d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C6
> > 36748453147406904&sdata=QcT4VTQth8GuXgjZejCsnFPDsMFbtqrUOW
> > uSDr8zbG8%3D&reserved=0
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ff
> > wll.ch&data=02%7C01%7Cdrawat%40vmware.com%7C5486d67be73647
> > b11d2708d62f58307d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7
> > C636748453147406904&sdata=4SKi8P5PeyCAUsoZh%2BsYFC%2FU2RiEx5
> > qp2gPP7bPr3Bo%3D&reserved=0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/6] lib/igt_vmwgfx: Add vmwgfx device
> > > This seems not needed? For pure generic kms tests I think it'd be great if > > > we don't have to sprinkle driver-specific checks all over. Which you seem > > > to achive in your series here. > > > > > > So not clear why this here is needed? > > > -Daniel > > > > Hi Daniel, > > > > Thanks for the review. You are right for kms tests having vmwgfx driver > type > > is not needed but I added vmwgfx device type because I plan to add more > > vmwgfx test cases, and since vmwgfx buffer allocation is private ioctl > > having a separate device type might be needed. > > Oh, this sounds awesome. And yes, for private ioctl tests vmwgfx is > obviuosly very much welcome! > > > I can drop this until I have some vmwgfx specific test cases. > > Sounds like a good plan to me. > -Daniel I saw latest email from Perti mentioning that this might be needed for loading ko. I am really not sure about that but I will test without vmwgfx as a separate driver type and see if things work. Thanks, Deepak ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/6] lib: Don't call igt_require_fb_modifiers() when no modifier
> On Wed, Oct 10, 2018 at 05:21:02PM -0700, Deepak Rawat wrote: > > vmwgfx doesn't support fb modifier so skip igt_require_fb_modifiers() > > when modifier are not passed. > > > > Signed-off-by: Deepak Rawat > > --- > > lib/ioctl_wrappers.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > > index 0929c43f..3a11cb6e 100644 > > --- a/lib/ioctl_wrappers.c > > +++ b/lib/ioctl_wrappers.c > > @@ -1678,7 +1678,10 @@ int __kms_addfb(int fd, uint32_t handle, > > struct drm_mode_fb_cmd2 f; > > int ret, i; > > > > - igt_require_fb_modifiers(fd); > > + if (modifier) > > + igt_require_fb_modifiers(fd); > > + else > > + flags &= ~DRM_MODE_FB_MODIFIERS; > > This would theoretically change the behviour for i915 at least. Without > the modifiers flag the kernel will pick the modifier for us based on > the bo tiling, which in theory might not be what we wanted. But at least > igt_fb should be fine with that. > > Maybe it would be better to just not pass the flags from the caller at > all, and instead have __kms_addfb() check if the driver has modifiers > or not and set the flag based on that? > Thanks Ville for the review. I thought of checking for modifiers support in __kms_addfb() but I discarded the idea as it looked an overkill to me, checking each time __kms_addfb() is called. May be static variable will be a good idea? And yes resetting the flag from caller looks a better way. Thanks, Deepak ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 4/6] lib: Don't call igt_require_fb_modifiers() when no modifier
On Thu, Oct 11, 2018 at 03:38:11PM +, Deepak Singh Rawat wrote: > > > On Wed, Oct 10, 2018 at 05:21:02PM -0700, Deepak Rawat wrote: > > > vmwgfx doesn't support fb modifier so skip igt_require_fb_modifiers() > > > when modifier are not passed. > > > > > > Signed-off-by: Deepak Rawat > > > --- > > > lib/ioctl_wrappers.c | 5 - > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > > > index 0929c43f..3a11cb6e 100644 > > > --- a/lib/ioctl_wrappers.c > > > +++ b/lib/ioctl_wrappers.c > > > @@ -1678,7 +1678,10 @@ int __kms_addfb(int fd, uint32_t handle, > > > struct drm_mode_fb_cmd2 f; > > > int ret, i; > > > > > > - igt_require_fb_modifiers(fd); > > > + if (modifier) > > > + igt_require_fb_modifiers(fd); > > > + else > > > + flags &= ~DRM_MODE_FB_MODIFIERS; > > > > This would theoretically change the behviour for i915 at least. Without > > the modifiers flag the kernel will pick the modifier for us based on > > the bo tiling, which in theory might not be what we wanted. But at least > > igt_fb should be fine with that. > > > > Maybe it would be better to just not pass the flags from the caller at > > all, and instead have __kms_addfb() check if the driver has modifiers > > or not and set the flag based on that? > > > > Thanks Ville for the review. I thought of checking for modifiers support > in __kms_addfb() but I discarded the idea as it looked an overkill to me, > checking each time __kms_addfb() is called. May be static variable will > be a good idea? And yes resetting the flag from caller looks a better way. I think simply removing the modifier flag iff the driver doesn't support modifiers _and_ the modifer is 0 would be ok. And yes probably better to do that in the higher-level calls that care. Just converting igt_fb should catch a lot of tests. There's 2 more crc tests you might care about, but vmwgfx doesn't have crc support so not really relevant. And maybe by then you do have modifier support :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/6] lib/igt_fb: Check for cairo surface success
> > On Wed, Oct 10, 2018 at 05:21:01PM -0700, Deepak Rawat wrote: > > For vmwgfx cairo surface creation fails due to stride mismatch, add a > > igt_require_f() for surface. > > Hmm. What kind of pixel format are you using? > > It seems to me cairo should be happy with just a 4 byte aligned > stride. How bad would it be to change vmw_dumb_create() to give > you that? Having working cairo stuff should make igt_fb much more > useful for you in general. I think pixel format was SVGA3D_R5G6B5. For vmwgfx pitch is simply width * bpp and for only some old length framebuffer, surface creation was failing. I didn't pursued this in much detail. Yes I plan to add vmwgfx private ioctl for buffer allocation to igt and I think that would solve this. > > Alternative would to not use dumb buffers I suppose, but then > we'd need to make sure the igt_fb size calculations are OK for > vmwgfx. Currently igt_fb assumes Intel hw in the sense that > linear buffers will get a 64byte aligned stride. > > > > > v2: Check for surface creation failure. > > > > Signed-off-by: Deepak Rawat > > --- > > lib/igt_fb.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/lib/igt_fb.c b/lib/igt_fb.c > > index 335ece69..1bb6d324 100644 > > --- a/lib/igt_fb.c > > +++ b/lib/igt_fb.c > > @@ -1433,6 +1433,10 @@ static void create_cairo_surface__gtt(int fd, > struct igt_fb *fb) > > cairo_image_surface_create_for_data(ptr, > > drm_format_to_cairo(fb- > >drm_format), > > fb->width, fb->height, fb- > >strides[0]); > > + igt_require_f(cairo_surface_status(fb->cairo_surface) == > CAIRO_STATUS_SUCCESS, > > + "Unable to create a cairo surface: %s\n", > > + cairo_status_to_string(cairo_surface_status(fb- > >cairo_surface))); > > + > > fb->domain = I915_GEM_DOMAIN_GTT; > > > > cairo_surface_set_user_data(fb->cairo_surface, > > -- > > 2.17.1 > > > > ___ > > igt-dev mailing list > > igt-...@lists.freedesktop.org > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fr > eedesktop.org%2Fmailman%2Flistinfo%2Figt- > dev&data=02%7C01%7Cdrawat%40vmware.com%7C55643c7eddb14e60 > aa3c08d62f8b500c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C63 > 6748672729440089&sdata=pE7NX1LoOz5qhBZhp%2F2wArWHvKdSF0ctx > TXyNW5%2Fcig%3D&reserved=0 > > -- > 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.IGT: success for drm/i915/selftests: Disable shrinker across mmap-exhaustion
== Series Details ==
Series: drm/i915/selftests: Disable shrinker across mmap-exhaustion
URL : https://patchwork.freedesktop.org/series/50857/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4969_full -> Patchwork_10424_full =
== Summary - SUCCESS ==
No regressions found.
== Known issues ==
Here are the changes found in Patchwork_10424_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@gem_exec_schedule@pi-ringfull-render:
shard-skl: NOTRUN -> FAIL (fdo#103158) +1
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-skl: NOTRUN -> TIMEOUT (fdo#108039)
igt@kms_available_modes_crc@available_mode_test_crc:
shard-apl: PASS -> FAIL (fdo#106641)
igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_cursor_crc@cursor-256x256-random:
shard-apl: PASS -> FAIL (fdo#103232) +1
igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
shard-glk: PASS -> DMESG-WARN (fdo#105763, fdo#106538) +1
igt@kms_fbcon_fbt@psr-suspend:
shard-skl: NOTRUN -> FAIL (fdo#107882)
igt@kms_flip@plain-flip-fb-recreate:
shard-skl: NOTRUN -> FAIL (fdo#100368)
igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-pwrite:
shard-glk: PASS -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-cpu:
shard-glk: PASS -> DMESG-FAIL (fdo#106538)
igt@kms_panel_fitting@legacy:
shard-skl: NOTRUN -> FAIL (fdo#105456)
{igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb}:
shard-skl: NOTRUN -> FAIL (fdo#108145)
{igt@kms_plane_alpha_blend@pipe-b-coverage-7efc}:
shard-skl: NOTRUN -> FAIL (fdo#108146) +1
igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
shard-apl: PASS -> FAIL (fdo#103166) +1
igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
shard-glk: PASS -> FAIL (fdo#103166)
igt@kms_rotation_crc@exhaust-fences:
shard-skl: NOTRUN -> DMESG-WARN (fdo#105748)
igt@pm_rpm@gem-evict-pwrite:
shard-skl: PASS -> INCOMPLETE (fdo#107807)
igt@pm_rpm@gem-idle:
shard-skl: NOTRUN -> INCOMPLETE (fdo#107807)
Possible fixes
igt@gem_exec_await@wide-contexts:
shard-glk: DMESG-FAIL -> PASS
igt@kms_cursor_crc@cursor-128x128-dpms:
shard-apl: FAIL (fdo#103232) -> PASS +1
igt@kms_flip@flip-vs-expired-vblank:
shard-kbl: FAIL (fdo#105363, fdo#102887) -> PASS
igt@kms_flip@plain-flip-fb-recreate-interruptible:
shard-skl: FAIL (fdo#100368) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
shard-glk: FAIL (fdo#103167) -> PASS +2
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
shard-apl: FAIL (fdo#103167) -> PASS +1
igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
shard-glk: FAIL (fdo#103166) -> PASS +1
Warnings
igt@kms_addfb_basic@bo-too-small-due-to-tiling:
shard-snb: DMESG-WARN (fdo#107469) -> INCOMPLETE (fdo#105411)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
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#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
fdo#105456 https://bugs.freedesktop.org/show_bug.cgi?id=105456
fdo#105748 https://bugs.freedesktop.org/show_bug.cgi?id=105748
fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641
fdo#107469 https://bugs.freedesktop.org/show_bug.cgi?id=107469
fdo#107807 https://bugs.freedesktop.org/show_bug.cgi?id=107807
fdo#107882 https://bugs.freedesktop.org/show_bug.cgi?id=107882
fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
fdo#108039 https://bugs.freedesktop.org/show_bug.cgi?id=108039
fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145
fdo#108146 https://bugs.freedesktop.org/show_bug.cgi?id=108146
== Participating hosts (6 -> 6) ==
No changes in participating hosts
== Build changes ==
* Linux: CI_DRM_4969 -> Patchwork_10424
CI_DRM_4969: 1121d2889e57dedacc0885deaaa9de614832e62f @
git://anongit.freedesktop
Re: [Intel-gfx] [PATCH] drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK
On Thu, Oct 11, 2018 at 02:30:41AM +0530, Mahesh Kumar wrote:
> On Thu, Oct 11, 2018 at 2:19 AM Mahesh Kumar
> wrote:
> >
> > Hi,
> >
> > On Wed, Oct 10, 2018 at 11:25 PM Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to
> > > the appropriate platforms.
> > >
> > > This was especially harsh on GLK since we don't even try to read
> > > the DIMM information on that platforms, hence valid_dimm was
> > > always false and thus we always tried to apply the w/a.
> > > Furthermore the w/a pushed the level 0 latency above the
> > > level 1 latency, which doesn't really make sense.
> > >
> > > Cc: Mahesh Kumar
> > > Cc: Maarten Lankhorst
> > > Fixes: 86b592876cb6 ("drm/i915: Implement 16GB dimm wa for latency
> > > level-0")
> > > 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 1392aa56a55a..a51cd09bbf75 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -2881,8 +2881,9 @@ static void intel_read_wm_latency(struct
> > > drm_i915_private *dev_priv,
> > > * any underrun. If not able to get Dimm info assume 16GB
> > > dimm
> > > * to avoid any underrun.
> > > */
> > > - if (!dev_priv->dram_info.valid_dimm ||
> > > - dev_priv->dram_info.is_16gb_dimm)
> > > + if (!IS_GEN9_LP(dev_priv) &&
> > > + (!dev_priv->dram_info.valid_dimm ||
> > > +dev_priv->dram_info.is_16gb_dimm))
> > > wm[0] += 1;
> >
> > I would rather prefer to update "intel_get_dram_info" to fill
> > valid_dimm and is_16gb_dimm info properly
> >
> > - if (INTEL_GEN(dev_priv) < 9 || IS_GEMINILAKE(dev_priv))
> > + if (INTEL_GEN(dev_priv) < 9 )
> > return;
> >
> > + if (IS_GEN9_LP(dev_priv)) {
> > + dram_info->valid_dimm = true;
> > + dram_info->is_16gb_dimm = false;
> > + }
> > +
> > +
> We don't want to proceed for GLK. So, something like:
>
> + if (IS_GEN9_LP(dev_priv)) {
> + dram_info->valid_dimm = true;
> + dram_info->is_16gb_dimm = false;
> + }
> +
I was going to do this initially but then I thought that it
might cause someone else to assume the dram info is actually
valid and rely on other stale data in there.
I guess a compromise is to ignore valid_dimm entirely and make
sure is_16gb_dimm is populated like we want for every platform.
Would probably need a comment to make sure no one extends the
16Gb dimm detection to cover BXT/GLK and accidentally re-enable
the w/a on those platforms (if they can even have 16Gb DIMMs?).
There's a bit of confusion in other parts of the dram detection
code as well. Eg. why does skl_dram_get_channels_info() set
valid_dimm=true before it configures is_16gb_dimm? There's a
return statement in between so we can be left with some kind
of bogus dram information, no?
> if (INTEL_GEN(dev_priv) < 9 || IS_GEMINILAKE(dev_priv))
> return;
>
> -Mahesh
> >
> > -Mahesh
> >
> > >
> > > } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> > > --
> > > 2.18.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 05/12] drm/i915: Add DEFINE_SNPRINTF_ARRAY()
On Thu, 11 Oct 2018, Ville Syrjälä wrote:
> On Thu, Oct 11, 2018 at 03:14:41PM +0300, Jani Nikula wrote:
>> On Wed, 10 Oct 2018, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Templatize snprintf_int_array() to allow us to print
>> > different kinds of arrays without having to type all
>> > the boilerplate for the snprintf() loop.
>>
>> I might just feel happier about duplicating the boilerplate...
>
> How about when the third user appears? :)
>
> Not sure I have a third user for this actually.
> snprintf_output_types() is pretty close, and there are other
> bitmask I'd probably like to decode. But I couldn't immediately
> think of a nice way to handle bitmasks and arrays in the same
> function.
So here's the non-macro generic approach. It's not perfect, it just has
different wrinkles:
static int snprintf_int(char *str, size_t len, const void *elem)
{
return snprintf(str, len, "%d", *((const int *)elem));
}
static void snprintf_array(char *str, size_t len, const void *array, int nelem,
size_t size, const char *sep,
int (*print)(char *str, size_t len, const void
*elem))
{
int i, r;
if (len)
str[0] = '\0';
for (i = 0; i < nelem; i++) {
const void *elem = array + i * size;
if (i) {
r = snprintf(str, len, "%s", sep);
if (r >= len)
return;
str += r;
len -= r;
}
r = print(str, len, elem);
if (r >= len)
return;
str += r;
len -= r;
}
}
static void snprintf_int_array(char *str, size_t len, const int *array, int
nelem)
{
snprintf_array(str, len, array, nelem, sizeof(array[0]), ", ",
snprintf_int);
}
Of course, this doesn't help with bitmasks either. You'd first have to
split the bitmask into an array.
BR,
Jani.
>
>>
>> BR,
>> Jani.
>>
>>
>>
>> >
>> > Signed-off-by: Ville Syrjälä
>> > ---
>> > drivers/gpu/drm/i915/i915_utils.h | 16
>> > drivers/gpu/drm/i915/intel_dp.c | 17 ++---
>> > 2 files changed, 18 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_utils.h
>> > b/drivers/gpu/drm/i915/i915_utils.h
>> > index 5858a43e19da..079aefa20bee 100644
>> > --- a/drivers/gpu/drm/i915/i915_utils.h
>> > +++ b/drivers/gpu/drm/i915/i915_utils.h
>> > @@ -161,4 +161,20 @@ static inline const char *enableddisabled(bool v)
>> >return v ? "enabled" : "disabled";
>> > }
>> >
>> > +#define DEFINE_SNPRINTF_ARRAY(name, type, values, index, fmt, ...) \
>> > +void name(char *_str, size_t _len, const type *values, int _nelems) \
>> > +{ \
>> > + int index; \
>> > + if (_len) \
>> > + _str[0] = '\0'; \
>> > + for (index = 0; index < _nelems; index++) { \
>> > + int _r = snprintf(_str, _len, "%s" fmt, \
>> > +index ? ", " : "", __VA_ARGS__); \
>> > + if (_r >= _len) \
>> > + return; \
>> > + _str += _r; \
>> > + _len -= _r; \
>> > + } \
>> > +}
>> > +
>> > #endif /* !__I915_UTILS_H */
>> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> > b/drivers/gpu/drm/i915/intel_dp.c
>> > index 13ff89be6ad6..dd8634b40179 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > @@ -1774,21 +1774,8 @@ intel_dp_set_clock(struct intel_encoder *encoder,
>> >}
>> > }
>> >
>> > -static void snprintf_int_array(char *str, size_t len,
>> > - const int *array, int nelem)
>> > -{
>> > - int i;
>> > -
>> > - str[0] = '\0';
>> > -
>> > - for (i = 0; i < nelem; i++) {
>> > - int r = snprintf(str, len, "%s%d", i ? ", " : "", array[i]);
>> > - if (r >= len)
>> > - return;
>> > - str += r;
>> > - len -= r;
>> > - }
>> > -}
>> > +static DEFINE_SNPRINTF_ARRAY(snprintf_int_array,
>> > + int, array, i, "%d", array[i]);
>> >
>> > static void intel_dp_print_rates(struct intel_dp *intel_dp)
>> > {
>>
>> --
>> 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] [PATCH] pci: Add a few new IDs for Intel GPU "spurious interrupt" quirk
On Thu, Oct 11, 2018 at 03:11:01PM +0800, Bin Meng wrote:
> On Wed, Oct 10, 2018 at 1:02 AM Bjorn Helgaas wrote:
> > On Mon, Oct 08, 2018 at 05:44:08PM +0800, Bin Meng wrote:
> > > On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
> > > > On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> > > > > On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas
> > > > > wrote:
> > > > > > On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> > > > > > > Add more PCI IDs to the Intel GPU "spurious interrupt" quirk
> > > > > > > table,
> > > > > > > which are known to break.
> > > > > >
> > > > > > Do you have a reference for this? Any public bug reports, bugzilla,
> > > > > > Intel spec reference or errata? "Which are known to break" is
> > > > > > pretty
> > > > > > vague.
> > > > >
> > > > > Sorry I used wrong words and should have been clearer. These devices
> > > > > are validated to be broken. The test I used is very simple, just
> > > > > unplug the VGA cable and plug it again, and "spurious interrupt" will
> > > > > be seen on the interrupt line of the IGD device. I was not aware of
> > > > > any public bugs filed to Intel, nor seen any errata from Intel.
> > > >
> > > > The original commit, f67fd55fa96f ("PCI: Add quirk for still enabled
> > > > interrupts on Intel Sandy Bridge GPUs"), says some systems "crash"
> > > > (not sure if that means an oops or an actual crash that requires a
> > > > reboot) and on other systems, Linux disables the shared interrupt
> > > > line. I assume disabling the interrupt line keeps devices using that
> > > > line from working, but does not directly cause a crash.
> > > >
> > >
> > > Correct, disable the shared interrupt line keeps all devices using
> > > that line from working, which is current kernel's behavior w/o this
> > > quirk handling: it disables the (shared) interrupt line after 100.000+
> > > generated interrupts. But the side effect is that other devices become
> > > unusable after that (eg: USB devices which share the same interrupt
> > > line with the Intel GPU). That's why the original commit, f67fd55fa96f
> > > ("PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge
> > > GPUs") disables the GPU's interrupt directly, which should really be
> > > done by the VGA BIOS itself (a buggy VBIOS!).
> > >
> > > > What specific symptom do you see here? I think it might be useful to
> > > > collect details, e.g., dmesg logs, /proc/interrupts contents, output
> > > > of "sudo lspci -vv", etc., for the systems you're quirking here. I'm
> > > > hoping we can eventually figure out a solution that doesn't require a
> > > > quirk for every new GPU, and maybe that info will help find it.
> > >
> > > The symptom was described briefly in the original commit f67fd55fa96f
> > > too, that disables the (shared) interrupt line after 100.000+
> > > generated interrupts (can be observed via /proc/interrupts).
> > >
> > > > > > > See commit f67fd55fa96f ("PCI: Add quirk for still enabled
> > > > > > > interrupts
> > > > > > > on Intel Sandy Bridge GPUs"), and commit 7c82126a94e6 ("PCI: Add
> > > > > > > new
> > > > > > > ID for Intel GPU "spurious interrupt" quirk") for some history.
> > > > > > >
> > > > > > > Based on current findings, it is highly possible that all Intel
> > > > > > > 1st/2nd/3rd generation Core processors' IGD has such quirk.
> > > > > >
> > > > > > Can you include a reference to these "current findings"? I assume
> > > > > > you
> > > > > > have bug reports that include the device IDs you're adding? If not,
> > > > > > how did you build this list of new IDs?
> > > > >
> > > > > By "current findings" I mean given the IDs we have here, plus previous
> > > > > one added by Thomas, it's highly possible this VGA BIOS bug exists in
> > > > > every 1st/2nd/3rd generation Core processors.
> > > > >
> > > > > > The function comment added by f67fd55fa96f ("PCI: Add quirk for
> > > > > > still
> > > > > > enabled interrupts on Intel Sandy Bridge GPUs") suggests that this
> > > > > > is
> > > > > > actually a BIOS issue, not a hardware erratum, i.e., I don't see
> > > > > > anything there that suggests a hardware defect.
> > > > > >
> > > > > > But there must be a hole somewhere -- the kernel can't be expected
> > > > > > to
> > > > > > disable interrupts in device-specific ways when there's no driver
> > > > > > loaded. Maybe it's simply a BIOS defect or maybe there's some
> > > > > > interrupt or _PRT-related setup we're missing.
> > > > >
> > > > > It's a pure VGA BIOS bug, not the BIOS bug or _PRT etc. The VGA BIOS
> > > > > forgot to turn off the interrupt on these devices.
> > > >
> > > > If this is a VGA BIOS defect, it's not very likely that it will
> > > > magically be fixed for all new Intel GPUs, so in effect it sounds like
> > > > we need to update this list of quirks in Linux every time a new Intel
> > > > GPU comes out. That prospect is a little daunting.
> > >
> > > I don't have a relatively newer Intel board at hand for te
Re: [Intel-gfx] [PATCH v3 04/18] drm/selftest: Add drm damage helper selftest
On Wed, Oct 10, 2018 at 05:16:43PM -0700, Deepak Rawat wrote:
> Selftest for drm damage helper iterator functions.
>
> Cc: ville.syrj...@linux.intel.com
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> Cc: intel-gfx@lists.freedesktop.org
> Cc: igt-...@lists.freedesktop.org
> Cc: petri.latv...@intel.com
> Cc: ch...@chris-wilson.co.uk
> Signed-off-by: Deepak Rawat
> ---
> drivers/gpu/drm/selftests/Makefile| 3 +-
> .../selftests/drm_damage_helper_selftests.h | 22 +
> .../drm/selftests/test-drm_damage_helper.c| 844 ++
> 3 files changed, 868 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
> create mode 100644 drivers/gpu/drm/selftests/test-drm_damage_helper.c
>
> diff --git a/drivers/gpu/drm/selftests/Makefile
> b/drivers/gpu/drm/selftests/Makefile
> index 9fc349fa18e9..88ac216f5962 100644
> --- a/drivers/gpu/drm/selftests/Makefile
> +++ b/drivers/gpu/drm/selftests/Makefile
> @@ -1 +1,2 @@
> -obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm-helper.o
> +obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm-helper.o \
> + test-drm_damage_helper.o
With the testcase intagrated into the test-drm-helper.ko module, for
patches 1-4 in this series:
Reviewed-by: Daniel Vetter
Obviously needs some adjusting on the igt side too, since we seem to be
missing the igt scaffolding for tests-drm-helper.ko.
-Daniel
> diff --git a/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
> b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
> new file mode 100644
> index ..3a1cbe05bef0
> --- /dev/null
> +++ b/drivers/gpu/drm/selftests/drm_damage_helper_selftests.h
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +selftest(damage_iter_no_damage, igt_damage_iter_no_damage)
> +selftest(damage_iter_no_damage_fractional_src,
> igt_damage_iter_no_damage_fractional_src)
> +selftest(damage_iter_no_damage_src_moved,
> igt_damage_iter_no_damage_src_moved)
> +selftest(damage_iter_no_damage_fractional_src_moved,
> igt_damage_iter_no_damage_fractional_src_moved)
> +selftest(damage_iter_no_damage_not_visible,
> igt_damage_iter_no_damage_not_visible)
> +selftest(damage_iter_no_damage_no_crtc, igt_damage_iter_no_damage_no_crtc)
> +selftest(damage_iter_no_damage_no_fb, igt_damage_iter_no_damage_no_fb)
> +selftest(damage_iter_simple_damage, igt_damage_iter_simple_damage)
> +selftest(damage_iter_single_damage, igt_damage_iter_single_damage)
> +selftest(damage_iter_single_damage_intersect_src,
> igt_damage_iter_single_damage_intersect_src)
> +selftest(damage_iter_single_damage_outside_src,
> igt_damage_iter_single_damage_outside_src)
> +selftest(damage_iter_single_damage_fractional_src,
> igt_damage_iter_single_damage_fractional_src)
> +selftest(damage_iter_single_damage_intersect_fractional_src,
> igt_damage_iter_single_damage_intersect_fractional_src)
> +selftest(damage_iter_single_damage_outside_fractional_src,
> igt_damage_iter_single_damage_outside_fractional_src)
> +selftest(damage_iter_single_damage_src_moved,
> igt_damage_iter_single_damage_src_moved)
> +selftest(damage_iter_single_damage_fractional_src_moved,
> igt_damage_iter_single_damage_fractional_src_moved)
> +selftest(damage_iter_damage, igt_damage_iter_damage)
> +selftest(damage_iter_damage_one_intersect,
> igt_damage_iter_damage_one_intersect)
> +selftest(damage_iter_damage_one_outside, igt_damage_iter_damage_one_outside)
> +selftest(damage_iter_damage_src_moved, igt_damage_iter_damage_src_moved)
> +selftest(damage_iter_damage_not_visible, igt_damage_iter_damage_not_visible)
> diff --git a/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> new file mode 100644
> index ..17754734c47a
> --- /dev/null
> +++ b/drivers/gpu/drm/selftests/test-drm_damage_helper.c
> @@ -0,0 +1,844 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Test case for drm_damage_helper functions
> + */
> +
> +#define pr_fmt(fmt) "drm_damage_helper: " fmt
> +
> +#include
> +#include
> +
> +#define TESTS "drm_damage_helper_selftests.h"
> +#include "drm_selftest.h"
> +
> +#define FAIL(test, msg, ...) \
> + do { \
> + if (test) { \
> + pr_err("%s/%u: " msg, __FUNCTION__, __LINE__,
> ##__VA_ARGS__); \
> + return -EINVAL; \
> + } \
> + } while (0)
> +
> +#define FAIL_ON(x) FAIL((x), "%s", "FAIL_ON(" __stringify(x) ")\n")
> +
> +static void set_plane_src(struct drm_plane_state *state, int x1, int y1, int
> x2,
> + int y2)
> +{
> + state->src.x1 = x1;
> + state->src.y1 = y1;
> + state->src.x2 = x2;
> + state->src.y2 = y2;
> +}
> +
> +static void set_damage_clip(struct drm_mode_rect *r, int x1, int y1, int x2,
> + int y2)
> +{
> + r->x1 = x1;
> + r->y1 = y1;
> + r->x2 = x2;
> + r->y2 =
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev4)
== Series Details ==
Series: drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture
(rev4)
URL : https://patchwork.freedesktop.org/series/34969/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4969_full -> Patchwork_10427_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10427_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10427_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_10427_full:
=== IGT changes ===
Warnings
igt@perf_pmu@rc6:
shard-kbl: PASS -> SKIP
igt@pm_rc6_residency@rc6-accuracy:
shard-snb: SKIP -> PASS
== Known issues ==
Here are the changes found in Patchwork_10427_full that come from known
issues:
=== IGT changes ===
Issues hit
igt@drv_hangman@error-state-capture-render:
shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359)
igt@gem_exec_schedule@pi-ringfull-blt:
shard-skl: NOTRUN -> FAIL (fdo#103158) +2
igt@gem_ppgtt@blt-vs-render-ctxn:
shard-skl: NOTRUN -> TIMEOUT (fdo#108039)
igt@gem_userptr_blits@readonly-unsync:
shard-skl: NOTRUN -> INCOMPLETE (fdo#108074)
igt@kms_available_modes_crc@available_mode_test_crc:
shard-apl: PASS -> FAIL (fdo#106641)
igt@kms_busy@extended-pageflip-hang-newfb-render-a:
shard-hsw: PASS -> DMESG-WARN (fdo#102614)
igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
shard-skl: NOTRUN -> DMESG-WARN (fdo#107956)
igt@kms_cursor_crc@cursor-128x128-random:
shard-apl: PASS -> FAIL (fdo#103232)
igt@kms_cursor_crc@cursor-64x64-dpms:
shard-glk: PASS -> FAIL (fdo#103232) +1
igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled:
shard-skl: PASS -> FAIL (fdo#103184)
igt@kms_fbcon_fbt@psr:
shard-skl: NOTRUN -> FAIL (fdo#107882)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
shard-skl: NOTRUN -> FAIL (fdo#103167)
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
shard-apl: PASS -> FAIL (fdo#103167) +1
igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
shard-glk: PASS -> FAIL (fdo#103167) +2
igt@kms_frontbuffer_tracking@fbc-stridechange:
shard-skl: NOTRUN -> FAIL (fdo#105683)
igt@kms_panel_fitting@legacy:
shard-skl: NOTRUN -> FAIL (fdo#105456)
igt@kms_pipe_crc_basic@read-crc-pipe-c:
shard-skl: NOTRUN -> FAIL (fdo#107362) +1
igt@kms_plane@plane-position-covered-pipe-c-planes:
shard-glk: PASS -> FAIL (fdo#103166) +1
{igt@kms_plane_alpha_blend@pipe-b-coverage-7efc}:
shard-skl: NOTRUN -> FAIL (fdo#108146)
{igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min}:
shard-skl: NOTRUN -> FAIL (fdo#108145) +1
igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
shard-apl: PASS -> FAIL (fdo#103166) +1
igt@perf_pmu@rc6-runtime-pm:
shard-glk: PASS -> FAIL (fdo#105010)
shard-apl: PASS -> FAIL (fdo#105010)
Possible fixes
igt@gem_exec_await@wide-contexts:
shard-glk: DMESG-FAIL (fdo#106680) -> PASS
igt@kms_cursor_crc@cursor-128x128-dpms:
shard-apl: FAIL (fdo#103232) -> PASS +1
igt@kms_flip@flip-vs-expired-vblank:
shard-kbl: FAIL (fdo#105363, fdo#102887) -> PASS
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
shard-glk: FAIL (fdo#103167) -> PASS +3
igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
shard-apl: FAIL (fdo#103167) -> PASS
{igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max}:
shard-glk: FAIL (fdo#108145) -> PASS
igt@pm_rpm@dpms-non-lpsp:
shard-skl: INCOMPLETE (fdo#107807) -> SKIP
Warnings
igt@kms_vblank@pipe-b-wait-forked:
shard-snb: DMESG-WARN (fdo#107469) -> INCOMPLETE (fdo#105411)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184
Re: [Intel-gfx] [PATCH 1/6] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+
Em Ter, 2018-10-09 às 16:55 -0700, Matt Roper escreveu:
> On Thu, Oct 04, 2018 at 04:15:55PM -0700, Paulo Zanoni wrote:
> > BSpec does not show these WAs as applicable to GLK, and for CNL it
> > only shows them applicable for a super early pre-production
> > stepping
> > we shouldn't be caring about anymore. Remove these so we can avoid
> > them on ICL too.
> >
> > Signed-off-by: Paulo Zanoni
>
> From a quick grep, it looks like there's a couple other CNL A0-
> specific
> workarounds in the codebase (in the watermark code). If we don't
> want
> to handle CNL A0 in this patch, then I think we should first land a
> patch that removes the others and updates
> intel_detect_preproduction_hw() to make it explicit that this is no
> longer a supported stepping.
This patch (and series) is potentially a "bug fix" due to changes in
real-world not-A0 hardware (although I didn't mark this one as a fix
since I doubt it will close anything in Bugzilla). The patch to remove
the implementation of WAs in CNL:A0 is not a bug fix, but a rework.
Fixes should always come before the reworks in order to facilitate
backporting efforts.
I do intend to propose patches removing the CNL A0 watermarks code
(along with other reworks I have in mind), but I wanted to sort the
bugs first.
>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 43 ++---
> >
> > 1 file changed, 23 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 1392aa56a55a..910551e04d16 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4687,28 +4687,31 @@ static int skl_compute_plane_wm(const
> > struct drm_i915_private *dev_priv,
> > res_lines = div_round_up_fixed16(selected_result,
> > wp-
> > >plane_blocks_per_line);
> >
> > - /* Display WA #1125: skl,bxt,kbl,glk */
> > - if (level == 0 && wp->rc_surface)
> > - res_blocks += fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > + if (IS_GEN9(dev_priv) && !IS_GEMINILAKE(dev_priv)) {
> > + /* Display WA #1125: skl,bxt,kbl */
>
> Although the code is right, should we just write "gen9" (or
> gen9display)
> in this comment (and the one for 1126)? That's how the bspec lists
> it
> (GEN9:All), and removes the ambiguity of whether "kbl" in this
> context
> is also supposed to cover CFL, AML, WHL (which it does).
Although that makes sense, it doesn't seem to follow the current
(undocumented?) standard we have for display WAs. I can totally do
this, but I would like some more opinions first. CC'ing the
maintainers.
Thanks for the reviews,
Paulo
>
>
> Matt
>
> > + if (level == 0 && wp->rc_surface)
> > + res_blocks +=
> > + fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > +
> > + /* Display WA #1126: skl,bxt,kbl */
> > + if (level >= 1 && level <= 7) {
> > + if (wp->y_tiled) {
> > + res_blocks +=
> > + fixed16_to_u32_round_up(wp-
> > >y_tile_minimum);
> > + res_lines += wp->y_min_scanlines;
> > + } else {
> > + res_blocks++;
> > + }
> >
> > - /* Display WA #1126: skl,bxt,kbl,glk */
> > - if (level >= 1 && level <= 7) {
> > - if (wp->y_tiled) {
> > - res_blocks += fixed16_to_u32_round_up(
> > - wp-
> > >y_tile_minimum);
> > - res_lines += wp->y_min_scanlines;
> > - } else {
> > - res_blocks++;
> > + /*
> > +* Make sure result blocks for higher
> > latency levels are
> > +* atleast as high as level below the
> > current level.
> > +* Assumption in DDB algorithm
> > optimization for special
> > +* cases. Also covers Display WA #1125 for
> > RC.
> > +*/
> > + if (result_prev->plane_res_b > res_blocks)
> > + res_blocks = result_prev-
> > >plane_res_b;
> > }
> > -
> > - /*
> > -* Make sure result blocks for higher latency
> > levels are atleast
> > -* as high as level below the current level.
> > -* Assumption in DDB algorithm optimization for
> > special cases.
> > -* Also covers Display WA #1125 for RC.
> > -*/
> > - if (result_prev->plane_res_b > res_blocks)
> > - res_blocks = result_prev->plane_res_b;
> > }
> >
> > if (INTEL_GEN(dev_priv) >= 11) {
> > --
> > 2.14.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
Re: [Intel-gfx] [PATCH] pci: Add a few new IDs for Intel GPU "spurious interrupt" quirk
Hi Bjorn,
On Wed, Oct 10, 2018 at 1:02 AM Bjorn Helgaas wrote:
>
> On Mon, Oct 08, 2018 at 05:44:08PM +0800, Bin Meng wrote:
> > On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
> > > On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> > > > On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas
> > > > wrote:
> > > > > On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> > > > > > Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table,
> > > > > > which are known to break.
> > > > >
> > > > > Do you have a reference for this? Any public bug reports, bugzilla,
> > > > > Intel spec reference or errata? "Which are known to break" is pretty
> > > > > vague.
> > > >
> > > > Sorry I used wrong words and should have been clearer. These devices
> > > > are validated to be broken. The test I used is very simple, just
> > > > unplug the VGA cable and plug it again, and "spurious interrupt" will
> > > > be seen on the interrupt line of the IGD device. I was not aware of
> > > > any public bugs filed to Intel, nor seen any errata from Intel.
> > >
> > > The original commit, f67fd55fa96f ("PCI: Add quirk for still enabled
> > > interrupts on Intel Sandy Bridge GPUs"), says some systems "crash"
> > > (not sure if that means an oops or an actual crash that requires a
> > > reboot) and on other systems, Linux disables the shared interrupt
> > > line. I assume disabling the interrupt line keeps devices using that
> > > line from working, but does not directly cause a crash.
> > >
> >
> > Correct, disable the shared interrupt line keeps all devices using
> > that line from working, which is current kernel's behavior w/o this
> > quirk handling: it disables the (shared) interrupt line after 100.000+
> > generated interrupts. But the side effect is that other devices become
> > unusable after that (eg: USB devices which share the same interrupt
> > line with the Intel GPU). That's why the original commit, f67fd55fa96f
> > ("PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge
> > GPUs") disables the GPU's interrupt directly, which should really be
> > done by the VGA BIOS itself (a buggy VBIOS!).
> >
> > > What specific symptom do you see here? I think it might be useful to
> > > collect details, e.g., dmesg logs, /proc/interrupts contents, output
> > > of "sudo lspci -vv", etc., for the systems you're quirking here. I'm
> > > hoping we can eventually figure out a solution that doesn't require a
> > > quirk for every new GPU, and maybe that info will help find it.
> >
> > The symptom was described briefly in the original commit f67fd55fa96f
> > too, that disables the (shared) interrupt line after 100.000+
> > generated interrupts (can be observed via /proc/interrupts).
> >
> > > > > > See commit f67fd55fa96f ("PCI: Add quirk for still enabled
> > > > > > interrupts
> > > > > > on Intel Sandy Bridge GPUs"), and commit 7c82126a94e6 ("PCI: Add new
> > > > > > ID for Intel GPU "spurious interrupt" quirk") for some history.
> > > > > >
> > > > > > Based on current findings, it is highly possible that all Intel
> > > > > > 1st/2nd/3rd generation Core processors' IGD has such quirk.
> > > > >
> > > > > Can you include a reference to these "current findings"? I assume you
> > > > > have bug reports that include the device IDs you're adding? If not,
> > > > > how did you build this list of new IDs?
> > > >
> > > > By "current findings" I mean given the IDs we have here, plus previous
> > > > one added by Thomas, it's highly possible this VGA BIOS bug exists in
> > > > every 1st/2nd/3rd generation Core processors.
> > > >
> > > > > The function comment added by f67fd55fa96f ("PCI: Add quirk for still
> > > > > enabled interrupts on Intel Sandy Bridge GPUs") suggests that this is
> > > > > actually a BIOS issue, not a hardware erratum, i.e., I don't see
> > > > > anything there that suggests a hardware defect.
> > > > >
> > > > > But there must be a hole somewhere -- the kernel can't be expected to
> > > > > disable interrupts in device-specific ways when there's no driver
> > > > > loaded. Maybe it's simply a BIOS defect or maybe there's some
> > > > > interrupt or _PRT-related setup we're missing.
> > > >
> > > > It's a pure VGA BIOS bug, not the BIOS bug or _PRT etc. The VGA BIOS
> > > > forgot to turn off the interrupt on these devices.
> > >
> > > If this is a VGA BIOS defect, it's not very likely that it will
> > > magically be fixed for all new Intel GPUs, so in effect it sounds like
> > > we need to update this list of quirks in Linux every time a new Intel
> > > GPU comes out. That prospect is a little daunting.
> >
> > I don't have a relatively newer Intel board at hand for testing right
> > now. I can try to locate one. But as I said, it's highly possible at
> > least all 1st/2nd/3rd generation Core processors are affected.
>
> > Maybe
> > we can add all these known GPU devices of 1st/2nd/3rd generation Core
> > processors all together for now? For newer GPUs, let's wait unt
