[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp_mst: Fix enabling pipe clock for all streams
== Series Details == Series: drm/i915/dp_mst: Fix enabling pipe clock for all streams URL : https://patchwork.freedesktop.org/series/49025/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4750_full -> Patchwork_10063_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10063_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-hsw: PASS -> INCOMPLETE (fdo#103540, fdo#106886) Possible fixes igt@gem_exec_await@wide-contexts: shard-kbl: FAIL (fdo#105900) -> PASS igt@gem_exec_suspend@basic-s3-devices: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_frontbuffer_tracking@fbc-suspend: shard-kbl: INCOMPLETE (fdo#103665, fdo#105959) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#105959 https://bugs.freedesktop.org/show_bug.cgi?id=105959 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4750 -> Patchwork_10063 CI_DRM_4750: ef9613f5ddd35f2bd2834489b6d96e54c0cae8c6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4618: 9d83154c898b5acc8b462d17104df50cfd71e9a0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10063: bb1f39c1120a86a6d33ca3c3fe8679e33a73f133 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10063/shards.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 drm/i915: Rename full ppgtt configuration to be more generic
== Series Details == Series: drm/i915: Rename full ppgtt configuration to be more generic URL : https://patchwork.freedesktop.org/series/49021/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4750_full -> Patchwork_10062_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10062_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-snb: PASS -> FAIL (fdo#106886) igt@kms_cursor_legacy@cursora-vs-flipa-toggle: shard-glk: PASS -> DMESG-WARN (fdo#105763) igt@kms_flip_tiling@flip-yf-tiled: shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) Possible fixes igt@gem_exec_await@wide-contexts: shard-kbl: FAIL (fdo#105900) -> PASS igt@gem_exec_suspend@basic-s3-devices: shard-snb: INCOMPLETE (fdo#105411) -> PASS 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#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4750 -> Patchwork_10062 CI_DRM_4750: ef9613f5ddd35f2bd2834489b6d96e54c0cae8c6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4618: 9d83154c898b5acc8b462d17104df50cfd71e9a0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10062: 605141a980b8ab7f839a294dc0a577f477907987 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10062/shards.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 drm/i915: Explicitly mark Global GTT address spaces
== Series Details == Series: drm/i915: Explicitly mark Global GTT address spaces URL : https://patchwork.freedesktop.org/series/49018/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4749_full -> Patchwork_10061_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10061_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106886) igt@gem_exec_suspend@basic-s3: shard-apl: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_eio@in-flight-contexts-10ms: shard-glk: FAIL -> PASS igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: shard-glk: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363, fdo#102887) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 == Participating hosts (6 -> 5) == Missing(1): pig-snb-2600 == Build changes == * Linux: CI_DRM_4749 -> Patchwork_10061 CI_DRM_4749: 4a46c18fad0de38a78b4b0c848892de494324a17 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4616: 5800e46c6f851c370c944a7cb169e99657239f8d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10061: a97af16a4feebcee5d0076479ff281eba089ffc2 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10061/shards.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 Load DMC v1.07 on Icelake (rev2)
== Series Details == Series: Load DMC v1.07 on Icelake (rev2) URL : https://patchwork.freedesktop.org/series/48773/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4749_full -> Patchwork_10060_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10060_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-hsw: PASS -> INCOMPLETE (fdo#106886, fdo#103540) shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106886) igt@gem_exec_await@wide-contexts: shard-glk: PASS -> FAIL (fdo#105900) igt@kms_cursor_crc@cursor-128x128-suspend: shard-apl: PASS -> FAIL (fdo#103232, fdo#103191, fdo#104645) igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: shard-apl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_exec_big: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: shard-glk: FAIL (fdo#104873) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363, fdo#102887) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104645 https://bugs.freedesktop.org/show_bug.cgi?id=104645 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 5) == Missing(1): pig-snb-2600 == Build changes == * Linux: CI_DRM_4749 -> Patchwork_10060 CI_DRM_4749: 4a46c18fad0de38a78b4b0c848892de494324a17 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4616: 5800e46c6f851c370c944a7cb169e99657239f8d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10060: 66f1af546312a6716f0abb2017145bba52c032ff @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10060/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 23/23] drm/i915/dp: Disable DSC in source by disabling DSS CTL bits
>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, July 31, 2018 2:07 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Singh, Gaurav K ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; Navare, Manasi D
>
>Subject: [PATCH v2 23/23] drm/i915/dp: Disable DSC in source by disabling DSS
>CTL bits
>
>From: Gaurav K Singh
>
>1. Disable Left/right VDSC branch in DSS Ctrl reg
>depending on the number of VDSC engines being used 2. Disable joiner in DSS
>Ctrl reg
>
>v5 (From Manasi):
>* Add Disable PG2 for VDSC on eDP
>v4: (From Manasi)
>* Rebase on top of revised patches
>v3 (From Manasi):
>* Use old_crtc_state to find dsc params
>* Add a condition to disable only if
>dsc state compression is enabled
>* Use correct DSS CTL regs
>v2 (From Manasi):
>* Fix tons of compilation errors like undefined variables, incorrect use of
>macros
>and all dirty laundry
>
>Cc: Jani Nikula
>Cc: Ville Syrjala
>Cc: Anusha Srivatsa
>Signed-off-by: Manasi Navare
>Signed-off-by: Gaurav K Singh
Reviewed-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 13
> drivers/gpu/drm/i915/intel_vdsc.c| 38
>
> 3 files changed, 53 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>index 0ffc9a7..cb6a80a 100644
>--- a/drivers/gpu/drm/i915/i915_drv.h
>+++ b/drivers/gpu/drm/i915/i915_drv.h
>@@ -3427,6 +3427,8 @@ extern bool intel_set_memory_cxsr(struct
>drm_i915_private *dev_priv,
> bool enable);
> extern void intel_dsc_enable(struct intel_encoder *encoder,
>struct intel_crtc_state *crtc_state);
>+extern void intel_dsc_disable(struct intel_encoder *encoder,
>+struct intel_crtc_state *crtc_state);
>
> int i915_reg_read_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file);
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index 6b1d151..2b0be6f 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -5829,6 +5829,9 @@ static void haswell_crtc_disable(struct intel_crtc_state
>*old_crtc_state,
> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
>+ struct drm_connector_state *conn_state;
>+ struct drm_connector *conn;
>+ int i;
>
> intel_encoders_disable(crtc, old_crtc_state, old_state);
>
>@@ -5845,6 +5848,16 @@ static void haswell_crtc_disable(struct
>intel_crtc_state *old_crtc_state,
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_ddi_disable_transcoder_func(old_crtc_state);
>
>+ for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>+ struct intel_encoder *encoder =
>+ to_intel_encoder(conn_state->best_encoder);
>+
>+ if (conn_state->crtc != crtc)
>+ continue;
>+
>+ intel_dsc_disable(encoder, old_crtc_state);
>+ }
>+
> if (INTEL_GEN(dev_priv) >= 9)
> skylake_scaler_disable(intel_crtc);
> else
>diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
>b/drivers/gpu/drm/i915/intel_vdsc.c
>index 32da285..96f6f94 100644
>--- a/drivers/gpu/drm/i915/intel_vdsc.c
>+++ b/drivers/gpu/drm/i915/intel_vdsc.c
>@@ -1048,3 +1048,41 @@ void intel_dsc_enable(struct intel_encoder *encoder,
>
> return;
> }
>+
>+void intel_dsc_disable(struct intel_encoder *encoder,
>+ struct intel_crtc_state *old_crtc_state) {
>+ struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>+ struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
>+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>+ enum pipe pipe = crtc->pipe;
>+ i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
>+ u32 dss_ctl1_val = 0, dss_ctl2_val = 0;
>+
>+ if (!old_crtc_state->dsc_params.compression_enable)
>+ return;
>+
>+ if (encoder->type == INTEL_OUTPUT_EDP) {
>+ dss_ctl1_reg = DSS_CTL1;
>+ dss_ctl2_reg = DSS_CTL2;
>+ } else {
>+ dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
>+ dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
>+ }
>+ dss_ctl1_val = I915_READ(dss_ctl1_reg);
>+ if (dss_ctl1_val & JOINER_ENABLE)
>+ dss_ctl1_val &= ~JOINER_ENABLE;
>+ I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
>+
>+ dss_ctl2_val = I915_READ(dss_ctl2_reg);
>+ if (dss_ctl2_val & LEFT_BRANCH_VDSC_ENABLE ||
>+ dss_ctl2_val & RIGHT_BRANCH_VDSC_ENABLE)
>+ dss_ctl2_val &= ~(LEFT_BRANCH_VDSC_ENABLE |
>+RIGHT_BRANCH_VDSC_ENABLE);
>+ I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
>+
>+ /* Put the PG2 power well for VDSC on eDP
Re: [Intel-gfx] [PATCH] drm/i915/dp_mst: Fix enabling pipe clock for all streams
On Fri, Aug 31, 2018 at 08:47:39PM +0300, Imre Deak wrote:
> commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
> inadvertently stopped enabling the pipe clock for any DP-MST stream
> after the first one. It also rearranged the pipe clock enabling wrt.
> initial MST payload allocation step (which may or may not be a
> problem, but it's contrary to the spec.).
>
> Fix things by making the above commit truly a non-functional change.
>
> Fixes: commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to
> encoders")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365
> Reported-by: Lyude Paul
> Reported-by: dmummensch...@web.de
> Tested-by: dmummensch...@web.de
> Cc: Lyude Paul
> Cc: dmummensch...@web.de
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Signed-off-by: Imre Deak
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_ddi.c| 17 +
> drivers/gpu/drm/i915/intel_dp_mst.c | 4
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f3b115ce4029..dcb1a98d624d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2912,7 +2912,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>
> icl_enable_phy_clock_gating(dig_port);
>
> - intel_ddi_enable_pipe_clock(crtc_state);
> + if (!is_mst)
> + intel_ddi_enable_pipe_clock(crtc_state);
> }
>
> static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> @@ -3015,14 +3016,14 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
> bool is_mst = intel_crtc_has_type(old_crtc_state,
> INTEL_OUTPUT_DP_MST);
>
> - intel_ddi_disable_pipe_clock(old_crtc_state);
> -
> - /*
> - * Power down sink before disabling the port, otherwise we end
> - * up getting interrupts from the sink on detecting link loss.
> - */
> - if (!is_mst)
> + if (!is_mst) {
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> + /*
> + * Power down sink before disabling the port, otherwise we end
> + * up getting interrupts from the sink on detecting link loss.
> + */
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + }
>
> intel_disable_ddi_buf(encoder);
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 352e5216cc65..77920f1a3da1 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -166,6 +166,8 @@ static void intel_mst_post_disable_dp(struct
> intel_encoder *encoder,
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
>
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> +
> /* this can fail */
> drm_dp_check_act_status(_dp->mst_mgr);
> /* and this can also fail */
> @@ -249,6 +251,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
> *encoder,
> I915_WRITE(DP_TP_STATUS(port), temp);
>
> ret = drm_dp_update_payload_part1(_dp->mst_mgr);
> +
> + intel_ddi_enable_pipe_clock(pipe_config);
> }
>
> static void intel_mst_enable_dp(struct intel_encoder *encoder,
> --
> 2.13.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rename full ppgtt configuration to be more generic
On Fri, Aug 31, 2018 at 04:51:29PM +0100, Chris Wilson wrote:
> Quoting Bob Paauwe (2018-08-31 16:47:04)
> > For ppgtt, what we're really interested in is the number of page
> > walk levels for each platform. Rename the device info fields to
> > reflect this:
> >
> > .has_full_48b_ppgtt -> .has_full_4lvl_ppgtt
> > .has_full_ppgtt -> .has_full_3lvl_ppgtt
> >
> > Also add a new field, full_ppgtt_bits, that defines the actual
> > address range. This gives us more flexibility and will work for
> > cases where we have platforms with different address ranges but
> > share the same page walk levels.
> >
> > Signed-off-by: Bob Paauwe
> > CC: Rodrigo Vivi
> > CC: Michel Thierry
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 +--
> > drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 34
> > +---
> > drivers/gpu/drm/i915/i915_params.c | 3 ++-
> > drivers/gpu/drm/i915/i915_pci.c | 17 +++-
> > drivers/gpu/drm/i915/intel_device_info.h | 7 +++--
> > drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
> > drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
> > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 2 +-
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 ++
> > 11 files changed, 45 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e5b9d3c77139..b9f7903e60d1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2569,8 +2569,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> > #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
> >
> > #define USES_PPGTT(dev_priv) (i915_modparams.enable_ppgtt)
> > -#define USES_FULL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
> > -#define USES_FULL_48BIT_PPGTT(dev_priv)
> > (i915_modparams.enable_ppgtt == 3)
> > +#define USES_FULL_3LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
> > +#define USES_FULL_4LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt == 3)
> > #define HAS_PAGE_SIZES(dev_priv, sizes) ({ \
> > GEM_BUG_ON((sizes) == 0); \
> > ((sizes) & ~(dev_priv)->info.page_sizes) == 0; \
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index f15a039772db..a0dc3170b358 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -361,7 +361,7 @@ i915_gem_create_context(struct drm_i915_private
> > *dev_priv,
> > if (IS_ERR(ctx))
> > return ctx;
> >
> > - if (USES_FULL_PPGTT(dev_priv)) {
> > + if (USES_FULL_3LVL_PPGTT(dev_priv)) {
>
> That is not an improvement. It really is a question of whether or not
> full-ppgtt is enabled.
I think we do need this change, but only with USES_FULL_PPGTT macro
and the rest should be checked with the full_ppgtt number of bits if
needed.
>
> > struct i915_hw_ppgtt *ppgtt;
> >
> > ppgtt = i915_ppgtt_create(dev_priv, file_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index a926d7d47183..166f1ea1786f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -2201,7 +2201,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > eb.flags = (unsigned int *)(eb.vma + args->buffer_count + 1);
> >
> > eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS;
> > - if (USES_FULL_PPGTT(eb.i915))
> > + if (USES_FULL_3LVL_PPGTT(eb.i915))
>
> Again the same complaint.
>
> I think you need to rethink the semantics carefully.
> -Chris
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp_mst: Fix enabling pipe clock for all streams
Tested on my T450s, fixes the regression with MST!
Consider this:
Tested-by: Lyude Paul
Reviewed-by: Lyude Paul
On Fri, 2018-08-31 at 20:47 +0300, Imre Deak wrote:
> commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
> inadvertently stopped enabling the pipe clock for any DP-MST stream
> after the first one. It also rearranged the pipe clock enabling wrt.
> initial MST payload allocation step (which may or may not be a
> problem, but it's contrary to the spec.).
>
> Fix things by making the above commit truly a non-functional change.
>
> Fixes: commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to
> encoders")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365
> Reported-by: Lyude Paul
> Reported-by: dmummensch...@web.de
> Tested-by: dmummensch...@web.de
> Cc: Lyude Paul
> Cc: dmummensch...@web.de
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_ddi.c| 17 +
> drivers/gpu/drm/i915/intel_dp_mst.c | 4
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f3b115ce4029..dcb1a98d624d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2912,7 +2912,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>
> icl_enable_phy_clock_gating(dig_port);
>
> - intel_ddi_enable_pipe_clock(crtc_state);
> + if (!is_mst)
> + intel_ddi_enable_pipe_clock(crtc_state);
> }
>
> static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> @@ -3015,14 +3016,14 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
> bool is_mst = intel_crtc_has_type(old_crtc_state,
> INTEL_OUTPUT_DP_MST);
>
> - intel_ddi_disable_pipe_clock(old_crtc_state);
> -
> - /*
> - * Power down sink before disabling the port, otherwise we end
> - * up getting interrupts from the sink on detecting link loss.
> - */
> - if (!is_mst)
> + if (!is_mst) {
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> + /*
> + * Power down sink before disabling the port, otherwise we end
> + * up getting interrupts from the sink on detecting link loss.
> + */
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + }
>
> intel_disable_ddi_buf(encoder);
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 352e5216cc65..77920f1a3da1 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -166,6 +166,8 @@ static void intel_mst_post_disable_dp(struct
> intel_encoder *encoder,
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
>
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> +
> /* this can fail */
> drm_dp_check_act_status(_dp->mst_mgr);
> /* and this can also fail */
> @@ -249,6 +251,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
> *encoder,
> I915_WRITE(DP_TP_STATUS(port), temp);
>
> ret = drm_dp_update_payload_part1(_dp->mst_mgr);
> +
> + intel_ddi_enable_pipe_clock(pipe_config);
> }
>
> static void intel_mst_enable_dp(struct intel_encoder *encoder,
--
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp_mst: Fix enabling pipe clock for all streams
On Fri, Aug 31, 2018 at 08:47:39PM +0300, Imre Deak wrote:
> commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
> inadvertently stopped enabling the pipe clock for any DP-MST stream
> after the first one. It also rearranged the pipe clock enabling wrt.
> initial MST payload allocation step (which may or may not be a
> problem, but it's contrary to the spec.).
>
> Fix things by making the above commit truly a non-functional change.
>
> Fixes: commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to
> encoders")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365
> Reported-by: Lyude Paul
> Reported-by: dmummensch...@web.de
> Tested-by: dmummensch...@web.de
> Cc: Lyude Paul
> Cc: dmummensch...@web.de
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_ddi.c| 17 +
> drivers/gpu/drm/i915/intel_dp_mst.c | 4
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f3b115ce4029..dcb1a98d624d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2912,7 +2912,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>
> icl_enable_phy_clock_gating(dig_port);
>
> - intel_ddi_enable_pipe_clock(crtc_state);
> + if (!is_mst)
> + intel_ddi_enable_pipe_clock(crtc_state);
> }
>
> static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> @@ -3015,14 +3016,14 @@ static void intel_ddi_post_disable_dp(struct
> intel_encoder *encoder,
> bool is_mst = intel_crtc_has_type(old_crtc_state,
> INTEL_OUTPUT_DP_MST);
>
> - intel_ddi_disable_pipe_clock(old_crtc_state);
> -
> - /*
> - * Power down sink before disabling the port, otherwise we end
> - * up getting interrupts from the sink on detecting link loss.
> - */
> - if (!is_mst)
> + if (!is_mst) {
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> + /*
> + * Power down sink before disabling the port, otherwise we end
> + * up getting interrupts from the sink on detecting link loss.
> + */
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> + }
>
> intel_disable_ddi_buf(encoder);
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 352e5216cc65..77920f1a3da1 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -166,6 +166,8 @@ static void intel_mst_post_disable_dp(struct
> intel_encoder *encoder,
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
>
> + intel_ddi_disable_pipe_clock(old_crtc_state);
> +
> /* this can fail */
> drm_dp_check_act_status(_dp->mst_mgr);
> /* and this can also fail */
> @@ -249,6 +251,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
> *encoder,
> I915_WRITE(DP_TP_STATUS(port), temp);
>
> ret = drm_dp_update_payload_part1(_dp->mst_mgr);
> +
> + intel_ddi_enable_pipe_clock(pipe_config);
> }
>
> static void intel_mst_enable_dp(struct intel_encoder *encoder,
> --
> 2.13.2
--
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 v3] drm/i915/dp: Configure Display stream splitter registers during DSC enable
>-Original Message-
>From: Navare, Manasi D
>Sent: Monday, August 6, 2018 12:41 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Navare, Manasi D ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha
>Subject: [PATCH v3] drm/i915/dp: Configure Display stream splitter registers
>during DSC enable
>
>Display Stream Splitter registers need to be programmed to enable the joiner if
>two DSC engines are used and also to enable the left and the right DSC engines.
>This happens as part of the DSC enabling routine in the source in atomic
>commit.
>
>v2:
>* Rebase (Manasi)
This is v2 of the patch correct?
No functional changes since the v1...only rebase. I got confused with the patch
prefix.
But the patch itself looks good, assuming this is the latest version:
Reviewed-by: Anusha Srivatsa
>Cc: Jani Nikula
>Cc: Ville Syrjala
>Cc: Anusha Srivatsa
>Signed-off-by: Manasi Navare
>---
> drivers/gpu/drm/i915/intel_vdsc.c | 21 +
> 1 file changed, 21 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
>b/drivers/gpu/drm/i915/intel_vdsc.c
>index 098f9b6..10e38396 100644
>--- a/drivers/gpu/drm/i915/intel_vdsc.c
>+++ b/drivers/gpu/drm/i915/intel_vdsc.c
>@@ -1011,6 +1011,11 @@ void intel_dsc_enable(struct intel_encoder *encoder,
>{
> struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
>+ enum pipe pipe = crtc->pipe;
>+ i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
>+ u32 dss_ctl1_val = 0;
>+ u32 dss_ctl2_val = 0;
>
> if (!crtc_state->dsc_params.compression_enable)
> return;
>@@ -1024,5 +1029,21 @@ void intel_dsc_enable(struct intel_encoder *encoder,
>
> intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
>
>+ /* Configure DSS_CTL registers for DSC */
>+ if (encoder->type == INTEL_OUTPUT_EDP) {
>+ dss_ctl1_reg = DSS_CTL1;
>+ dss_ctl2_reg = DSS_CTL2;
>+ } else {
>+ dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
>+ dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
>+ }
>+ dss_ctl2_val |= LEFT_BRANCH_VDSC_ENABLE;
>+ if (crtc_state->dsc_params.dsc_split) {
>+ dss_ctl2_val |= RIGHT_BRANCH_VDSC_ENABLE;
>+ dss_ctl1_val |= JOINER_ENABLE;
>+ }
>+ I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
>+ I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
>+
> return;
> }
>--
>2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 20/23] drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes
>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, July 31, 2018 2:07 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Navare, Manasi D ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha
>Subject: [PATCH v2 20/23] drm/i915/dp: Populate DSC PPS SDP and send PPS
>infoframes
>
>DSC PPS secondary data packet infoframes are filled with DSC picure parameter
>set metadata according to the DSC standard.
>These infoframes are sent to the sink device and used during DSC decoding.
>
>Cc: Jani Nikula
>Cc: Ville Syrjala
>Cc: Anusha Srivatsa
>Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/intel_vdsc.c | 21 +
> 1 file changed, 21 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
>b/drivers/gpu/drm/i915/intel_vdsc.c
>index e3db9dc..bd5dc96 100644
>--- a/drivers/gpu/drm/i915/intel_vdsc.c
>+++ b/drivers/gpu/drm/i915/intel_vdsc.c
>@@ -988,6 +988,25 @@ static void intel_configure_pps_for_dsc_encoder(struct
>intel_encoder *encoder,
> }
> }
>
>+static void intel_dp_send_dsc_pps_sdp(struct intel_encoder *encoder,
>+struct intel_crtc_state *crtc_state) {
>+ struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>+ struct drm_dsc_config *vdsc_cfg = _state->dp_dsc_cfg;
>+ struct drm_dsc_pps_infoframe dp_dsc_pps_sdp;
>+
>+ /* Prepare DP SDP PPS header as per DP 1.4 spec, Table 2-123 */
>+ drm_dsc_dp_pps_header_init(_dsc_pps_sdp);
>+
>+ /* Fill the PPS payload bytes as per DSC spec 1.2 Table 4-1 */
>+ drm_dsc_pps_infoframe_pack(_dsc_pps_sdp, vdsc_cfg);
>+
>+ intel_dig_port->write_infoframe(>base, crtc_state,
>+ DP_SDP_PPS, _dsc_pps_sdp,
>+ sizeof(dp_dsc_pps_sdp));
>+}
>+
> void intel_dsc_enable(struct intel_encoder *encoder,
> struct intel_crtc_state *crtc_state) { @@ -1003,5 +1022,7
>@@ void intel_dsc_enable(struct intel_encoder *encoder,
>
> intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
>
>+ intel_dp_send_dsc_pps_sdp(encoder, crtc_state);
>+
> return;
> }
>--
>2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 17/23] drm/i915/dp: Enable/Disable DSC in DP Sink
>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, July 31, 2018 2:07 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Singh, Gaurav K ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; Navare, Manasi D
>
>Subject: [PATCH v2 17/23] drm/i915/dp: Enable/Disable DSC in DP Sink
>
>From: Gaurav K Singh
>
>This patch enables decompression support in sink device before link training
>and
>disables the same during the DDI disabling.
>
>v2:(From Manasi)
>* Change the enable/disable function to take crtc_state instead of intel_dp as
>an
>argument (Manasi)
>* Use the compression_enable flag as part of crtc_state (Manasi)
>
>Cc: Jani Nikula
>Cc: Ville Syrjala
>Cc: Anusha Srivatsa
>Cc: Gaurav K Singh
>Signed-off-by: Gaurav K Singh
>Signed-off-by: Manasi Navare
Looks good. Setting the state at the right time.
Reviewed-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/intel_ddi.c | 5 + drivers/gpu/drm/i915/intel_dp.c
> |
>15 +++ drivers/gpu/drm/i915/intel_drv.h | 3 +++
> 3 files changed, 23 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>b/drivers/gpu/drm/i915/intel_ddi.c
>index 0adc043..5e8c891 100644
>--- a/drivers/gpu/drm/i915/intel_ddi.c
>+++ b/drivers/gpu/drm/i915/intel_ddi.c
>@@ -2825,6 +2825,8 @@ static void intel_ddi_pre_enable_dp(struct
>intel_encoder *encoder,
> intel_ddi_init_dp_buf_reg(encoder);
> if (!is_mst)
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>+ intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
>+DP_DECOMPRESSION_EN);
> intel_dp_start_link_train(intel_dp);
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
>@@ -3154,6 +3156,9 @@ static void intel_disable_ddi_dp(struct intel_encoder
>*encoder,
> intel_edp_drrs_disable(intel_dp, old_crtc_state);
> intel_psr_disable(intel_dp, old_crtc_state);
> intel_edp_backlight_off(old_conn_state);
>+ /* Disable the decompression in DP Sink */
>+ intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
>+~DP_DECOMPRESSION_EN);
> }
>
> static void intel_disable_ddi_hdmi(struct intel_encoder *encoder, diff --git
>a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index
>dc0a3c2..1a8329c 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -2925,6 +2925,21 @@ static bool downstream_hpd_needs_d0(struct
>intel_dp *intel_dp)
> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD; }
>
>+void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
>+ const struct intel_crtc_state
>*crtc_state,
>+ int state)
>+{
>+ int ret;
>+
>+ if (!crtc_state->dsc_params.compression_enable)
>+ return;
>+
>+ ret = drm_dp_dpcd_writeb(_dp->aux, DP_DSC_ENABLE, state);
>+ if (ret < 0)
>+ DRM_DEBUG_KMS("Failed to %s sink decompression state\n",
>+state == DP_DECOMPRESSION_EN ? "enable" :
>"disable"); }
>+
> /* If the sink supports it, try to set the power state appropriately */ void
>intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) { diff --git
>a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
>index 33cc777..ced62e0 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -1691,6 +1691,9 @@ void intel_dp_stop_link_train(struct intel_dp
>*intel_dp); int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_modeset_acquire_ctx *ctx); void
>intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
>+void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
>+ const struct intel_crtc_state
>*crtc_state,
>+ int state);
> void intel_dp_encoder_reset(struct drm_encoder *encoder); void
>intel_dp_encoder_suspend(struct intel_encoder *intel_encoder); void
>intel_dp_encoder_destroy(struct drm_encoder *encoder);
>--
>2.7.4
___
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/dp_mst: Fix enabling pipe clock for all streams
== Series Details ==
Series: drm/i915/dp_mst: Fix enabling pipe clock for all streams
URL : https://patchwork.freedesktop.org/series/49025/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4750 -> Patchwork_10063 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49025/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10063 that come from known issues:
=== IGT changes ===
Possible fixes
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: FAIL (fdo#103191, fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: FAIL (fdo#104008) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
== Participating hosts (52 -> 48) ==
Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4750 -> Patchwork_10063
CI_DRM_4750: ef9613f5ddd35f2bd2834489b6d96e54c0cae8c6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4618: 9d83154c898b5acc8b462d17104df50cfd71e9a0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10063: bb1f39c1120a86a6d33ca3c3fe8679e33a73f133 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
bb1f39c1120a drm/i915/dp_mst: Fix enabling pipe clock for all streams
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10063/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp_mst: Fix enabling pipe clock for all streams
commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to encoders")
inadvertently stopped enabling the pipe clock for any DP-MST stream
after the first one. It also rearranged the pipe clock enabling wrt.
initial MST payload allocation step (which may or may not be a
problem, but it's contrary to the spec.).
Fix things by making the above commit truly a non-functional change.
Fixes: commit afb2c4437dae ("drm/i915/ddi: Push pipe clock enabling to
encoders")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107365
Reported-by: Lyude Paul
Reported-by: dmummensch...@web.de
Tested-by: dmummensch...@web.de
Cc: Lyude Paul
Cc: dmummensch...@web.de
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_ddi.c| 17 +
drivers/gpu/drm/i915/intel_dp_mst.c | 4
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f3b115ce4029..dcb1a98d624d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2912,7 +2912,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
icl_enable_phy_clock_gating(dig_port);
- intel_ddi_enable_pipe_clock(crtc_state);
+ if (!is_mst)
+ intel_ddi_enable_pipe_clock(crtc_state);
}
static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
@@ -3015,14 +3016,14 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
bool is_mst = intel_crtc_has_type(old_crtc_state,
INTEL_OUTPUT_DP_MST);
- intel_ddi_disable_pipe_clock(old_crtc_state);
-
- /*
-* Power down sink before disabling the port, otherwise we end
-* up getting interrupts from the sink on detecting link loss.
-*/
- if (!is_mst)
+ if (!is_mst) {
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+ /*
+* Power down sink before disabling the port, otherwise we end
+* up getting interrupts from the sink on detecting link loss.
+*/
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+ }
intel_disable_ddi_buf(encoder);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 352e5216cc65..77920f1a3da1 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -166,6 +166,8 @@ static void intel_mst_post_disable_dp(struct intel_encoder
*encoder,
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
+ intel_ddi_disable_pipe_clock(old_crtc_state);
+
/* this can fail */
drm_dp_check_act_status(_dp->mst_mgr);
/* and this can also fail */
@@ -249,6 +251,8 @@ static void intel_mst_pre_enable_dp(struct intel_encoder
*encoder,
I915_WRITE(DP_TP_STATUS(port), temp);
ret = drm_dp_update_payload_part1(_dp->mst_mgr);
+
+ intel_ddi_enable_pipe_clock(pipe_config);
}
static void intel_mst_enable_dp(struct intel_encoder *encoder,
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rename full ppgtt configuration to be more generic
On Fri, 31 Aug 2018 16:51:29 +0100
Chris Wilson wrote:
> Quoting Bob Paauwe (2018-08-31 16:47:04)
> > For ppgtt, what we're really interested in is the number of page
> > walk levels for each platform. Rename the device info fields to
> > reflect this:
> >
> > .has_full_48b_ppgtt -> .has_full_4lvl_ppgtt
> > .has_full_ppgtt -> .has_full_3lvl_ppgtt
> >
> > Also add a new field, full_ppgtt_bits, that defines the actual
> > address range. This gives us more flexibility and will work for
> > cases where we have platforms with different address ranges but
> > share the same page walk levels.
> >
> > Signed-off-by: Bob Paauwe
> > CC: Rodrigo Vivi
> > CC: Michel Thierry
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 +--
> > drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 34
> > +---
> > drivers/gpu/drm/i915/i915_params.c | 3 ++-
> > drivers/gpu/drm/i915/i915_pci.c | 17 +++-
> > drivers/gpu/drm/i915/intel_device_info.h | 7 +++--
> > drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
> > drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
> > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 2 +-
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 ++
> > 11 files changed, 45 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e5b9d3c77139..b9f7903e60d1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2569,8 +2569,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> > #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
> >
> > #define USES_PPGTT(dev_priv) (i915_modparams.enable_ppgtt)
> > -#define USES_FULL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
> > -#define USES_FULL_48BIT_PPGTT(dev_priv)
> > (i915_modparams.enable_ppgtt == 3)
> > +#define USES_FULL_3LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
> > +#define USES_FULL_4LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt == 3)
> > #define HAS_PAGE_SIZES(dev_priv, sizes) ({ \
> > GEM_BUG_ON((sizes) == 0); \
> > ((sizes) & ~(dev_priv)->info.page_sizes) == 0; \
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index f15a039772db..a0dc3170b358 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -361,7 +361,7 @@ i915_gem_create_context(struct drm_i915_private
> > *dev_priv,
> > if (IS_ERR(ctx))
> > return ctx;
> >
> > - if (USES_FULL_PPGTT(dev_priv)) {
> > + if (USES_FULL_3LVL_PPGTT(dev_priv)) {
>
> That is not an improvement. It really is a question of whether or not
> full-ppgtt is enabled.
>
> > struct i915_hw_ppgtt *ppgtt;
> >
> > ppgtt = i915_ppgtt_create(dev_priv, file_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index a926d7d47183..166f1ea1786f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -2201,7 +2201,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> > eb.flags = (unsigned int *)(eb.vma + args->buffer_count + 1);
> >
> > eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS;
> > - if (USES_FULL_PPGTT(eb.i915))
> > + if (USES_FULL_3LVL_PPGTT(eb.i915))
>
> Again the same complaint.
>
> I think you need to rethink the semantics carefully.
> -Chris
Would USES_FULL_PPGTT() and USES_EXTENDED_PPGTT() make more sense
then? I think the biggest issue is with the FULL_48BIT_PPGTT name
going forward.
Bob
--
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp. Folsom, CA
(916) 356-6193
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix context RPCS programming
On 31/08/2018 12:53, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
There are two issues with the current RPCS programming for Icelake:
Expansion of the slice count bitfield has been missed, as well as the
required programming workaround for the subslice count bitfield size
limitation.
1)
Bitfield width for configuring the active slice count has grown so we need
to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
2)
Due subslice count bitfield being only three bits wide and furthermore
capped to a maximum documented value of four, special programming
workaround is needed to enable more than four subslices.
With this programming driver has to consider the GT configuration as
2x4x8, while the hardware internally translates this to 1x8x8.
A limitation stemming from this is that either a subslice count between
one and four can be selected, or a subslice count equaling the total
number of subslices in all selected slices. In other words, odd subslice
counts greater than four are impossible, as are odd subslice counts
greater than a single slice subslice count.
This also had no impact in the current code base due breakage from 1)
always reqesting more than one slice.
While fixing this we also add some asserts to flag up any future bitfield
overflows.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_lrc.c | 89 +++-
2 files changed, 78 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f2321785cbd6..09bc8e730ee1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT 15
#define GEN8_RPCS_S_CNT_MASK(0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK(0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK (0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f8ceb9c99dd6..323c46319cb8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2480,6 +2480,9 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
static u32
make_rpcs(struct drm_i915_private *dev_priv)
{
+ bool subslice_pg = INTEL_INFO(dev_priv)->sseu.has_subslice_pg;
+ u8 slices = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+ u8 subslices = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
u32 rpcs = 0;
/*
@@ -2489,6 +2492,38 @@ make_rpcs(struct drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) < 9)
return 0;
+ /*
+* Since the SScount bitfield in GEN8_R_PWR_CLK_STATE is only three bits
+* wide and Icelake has up to eight subslices, specfial programming is
+* needed in order to correctly enable all subslices.
+*
+* According to documentation software must consider the configuration
+* as 2x4x8 and hardware will translate this to 1x8x8.
+*
+* Furthemore, even though SScount is three bits, maximum documented
+* value for it is four. From this some rules/restrictions follow:
+*
+* 1.
+* If enabled subslice count is greater than four, two whole slices must
+* be enabled instead.
+*
+* 2.
+* When more than one slice is enabled, hardware ignores the subslice
+* count altogether.
+*
+* From these restrictions it follows that it is not possible to enable
+* a count of subslices between the SScount maximum of four restriction,
+* and the maximum available number on a particular SKU. Either all
+* subslices are enabled, or a count between one and four on the first
+* slice.
+*/
+ if (IS_GEN11(dev_priv) && slices == 1 && subslices >= 4) {
+ GEM_BUG_ON(subslices & 1);
+
+ subslice_pg = false;
Err... Now I'm looking at the documentation again and I see this for the
subslice enable field :
Enable Subslice Count Request.
0 = Use Async subslice count
1 = Use
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Rename full ppgtt configuration to be more generic
== Series Details ==
Series: drm/i915: Rename full ppgtt configuration to be more generic
URL : https://patchwork.freedesktop.org/series/49021/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4750 -> Patchwork_10062 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49021/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10062 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-kbl-guc: PASS -> DMESG-FAIL (fdo#107710, fdo#106947)
igt@gem_exec_suspend@basic-s4-devices:
fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128, fdo#107139)
fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718)
Possible fixes
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: FAIL (fdo#104008) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710
fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
== Participating hosts (52 -> 47) ==
Missing(5): fi-hsw-4770r fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4750 -> Patchwork_10062
CI_DRM_4750: ef9613f5ddd35f2bd2834489b6d96e54c0cae8c6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4618: 9d83154c898b5acc8b462d17104df50cfd71e9a0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10062: 605141a980b8ab7f839a294dc0a577f477907987 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
605141a980b8 drm/i915: Rename full ppgtt configuration to be more generic
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10062/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 drm/i915/icl: Fix context RPCS programming
== Series Details == Series: drm/i915/icl: Fix context RPCS programming URL : https://patchwork.freedesktop.org/series/49005/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4748_full -> Patchwork_10059_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10059_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10059_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_10059_full: === IGT changes === Warnings igt@pm_rc6_residency@rc6-accuracy: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_10059_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@vecs0-s3: shard-kbl: PASS -> DMESG-WARN (fdo#103313) igt@gem_ppgtt@blt-vs-render-ctx0: shard-snb: NOTRUN -> INCOMPLETE (fdo#106887, fdo#105411) shard-kbl: PASS -> INCOMPLETE (fdo#106023, fdo#103665) igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip@flip-vs-dpms-off-vs-modeset: shard-apl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +5 Possible fixes igt@gem_exec_store@pages-blt: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_cursor_crc@cursor-256x256-suspend: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-varying-size: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: shard-glk: FAIL (fdo#103167) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106887 https://bugs.freedesktop.org/show_bug.cgi?id=106887 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4748 -> Patchwork_10059 CI_DRM_4748: 6caeb081ceb9282503439565e7093c1032758289 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4613: 3f89d7b02dcf662e994c7135b13d52bc8e09a4ea @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10059: 8b03edf949e3c9c6d97154e40c11f1f0d2a1aec7 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10059/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm v2 4/5] intel: make gen9 use generic gen macro
On Fri, Aug 31, 2018 at 09:21:32AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-29 01:35:31)
> > The 2 PCI IDs that are used for the command line overrid mechanism
> > were left defined. The rest can be gone and then we just use the kernel
> > defines.
> >
> > Signed-off-by: Lucas De Marchi
> > ---
> > intel/intel_chipset.c | 5 ++
> > intel/intel_chipset.h | 187 +-
> > 2 files changed, 6 insertions(+), 186 deletions(-)
> >
> > diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
> > index 0c2ba884..c984d8ac 100644
> > --- a/intel/intel_chipset.c
> > +++ b/intel/intel_chipset.c
> > @@ -36,6 +36,11 @@ static const struct pci_device {
> > } pciids[] = {
> > INTEL_ICL_11_IDS(11),
> > INTEL_CNL_IDS(10),
> > + INTEL_CFL_IDS(9),
> > + INTEL_GLK_IDS(9),
> > + INTEL_KBL_IDS(9),
> > + INTEL_BXT_IDS(9),
> > + INTEL_SKL_IDS(9),
>
> The gradual conversion lgtm. But why stop here? :)
From cover letter:
Initially my plan was to convert all gens, back to gen2, but
that proved slightly difficult since there are some corner cases
to cover and I didn't want to block the important part, i.e.:
for recent gens, there's no risk of missing a PCI ID.
With the last approach moving the implementation to a .c file I think it
will be easier to implement for older gens, but there's no point in
doing the manual boring labor of converting all gens just to have to
change the approach in a v2, v3 of the patch set. Like I did for v1 ->
v2. I can convert the rest if we agree the current approach is
okish
I'm even ok with letting older ones as is since I hope we won't add a
new pci id for e.g. gen3, so I won't have to touch that.
Lucas De Marchi
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm v2 1/5] intel: add generic functions to check PCI ID
Quoting Lucas De Marchi (2018-08-31 17:06:01)
> On Fri, Aug 31, 2018 at 09:16:23AM +0100, Chris Wilson wrote:
> > Quoting Lucas De Marchi (2018-08-29 01:35:28)
> > > +bool intel_is_genx(unsigned int devid, int gen)
> > > +{
> > > + const struct pci_device *p,
> > > + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> > > +
> > > + for (p = pciids; p < pend; p++) {
> > > + /* PCI IDs are sorted */
> > > + if (p->gen < gen)
> > > + break;
> >
> > If we have lots of gen with lots of subids, a binary search for gen
> > would be sensible. However, do we need this function? Do we not just
> > convert everyone over to a lookup of pci-id on entry?
>
> in some places we need the single IS_GEN9(). The advantage of using this
> function rather than intel_get_genx() is that it can be faster due to
> stopping here, or doing a binary search as you pointed out.
> With intel_get_genx we don't have this. IS_GEN9() is may be called in
> non-initialization code paths, so IMO its worth.
>
> What we *can* do here instead is: guarantee all codepaths will occur
> after the call to drm_intel_bufmgr_gem_init() then remove all macros and
> just implement a single function that checks the "cached value".
That would be similar to how we handle elsewhere. But there's no need to
jump there in one series.
> > Idle thought
> > #ifdef SELFTEST
> > int main(void)
> > {
> > /* check pci-ids are ordered by gen */
> > }
> > #endif
>
> $ git grep SELFTEST
> $
>
> you do know this is a patch for libdrm, right?
Wouldn't be that hard to add a check_PROGRAMS target with a -DSELFTEST.
It was just an idle thought if you cared to improve the standard of a
stagnant library. It might as well retire with grace ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm v2 1/5] intel: add generic functions to check PCI ID
On Fri, Aug 31, 2018 at 09:16:23AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-29 01:35:28)
> > +static const struct pci_device {
> > + uint16_t device;
> > + uint16_t gen;
> > +} pciids[] = {
>
> Add a comment here as well for the ordering requirement.
>
> /* Keep ids sorted by gen; latest gen first */
>
> We're unlikely to notice a comment in the function later trying to
> impose its restriction.
ok
>
> > +};
> > +
> > +bool intel_is_genx(unsigned int devid, int gen)
> > +{
> > + const struct pci_device *p,
> > + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> > +
> > + for (p = pciids; p < pend; p++) {
> > + /* PCI IDs are sorted */
> > + if (p->gen < gen)
> > + break;
>
> If we have lots of gen with lots of subids, a binary search for gen
> would be sensible. However, do we need this function? Do we not just
> convert everyone over to a lookup of pci-id on entry?
in some places we need the single IS_GEN9(). The advantage of using this
function rather than intel_get_genx() is that it can be faster due to
stopping here, or doing a binary search as you pointed out.
With intel_get_genx we don't have this. IS_GEN9() is may be called in
non-initialization code paths, so IMO its worth.
What we *can* do here instead is: guarantee all codepaths will occur
after the call to drm_intel_bufmgr_gem_init() then remove all macros and
just implement a single function that checks the "cached value".
>
> > +
> > + if (p->device != devid)
> > + continue;
> > +
> > + if (gen == p->gen)
> > + return true;
> > +
> > + break;
> > + }
> > +
> > + return false;
> > +}
> > +
> > +bool intel_get_genx(unsigned int devid, int *gen)
> > +{
> > + const struct pci_device *p,
> > + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> > +
> > + for (p = pciids; p < pend; p++) {
> > + if (p->device != devid)
> > + continue;
> > +
> > + if (gen)
> > + *gen = p->gen;
> > +
> > + return true;
> > + }
> > +
> > + return false;
> > +}
>
> Idle thought
> #ifdef SELFTEST
> int main(void)
> {
> /* check pci-ids are ordered by gen */
> }
> #endif
$ git grep SELFTEST
$
you do know this is a patch for libdrm, right?
>
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 4a34b7be..0e14c58f 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -568,6 +568,13 @@
> >
> > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> >
> > +/* New platforms use kernel pci ids */
> > +#include
> > +
> > +bool intel_is_genx(unsigned int devid, int gen);
> > +bool intel_get_genx(unsigned int devid, int *gen);
> > +
> > +/* all platforms */
>
> Quite clearly not all platforms :-p
by some definition of "all" the " New platforms use kernel pci ids " + the
ones that don't ;)
I'm ok with just removing the comment
Lucas De Marchi
>
> > #define IS_9XX(dev)(IS_GEN3(dev) || \
> > IS_GEN4(dev) || \
> > IS_GEN5(dev) || \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rename full ppgtt configuration to be more generic
Quoting Bob Paauwe (2018-08-31 16:47:04)
> For ppgtt, what we're really interested in is the number of page
> walk levels for each platform. Rename the device info fields to
> reflect this:
>
> .has_full_48b_ppgtt -> .has_full_4lvl_ppgtt
> .has_full_ppgtt -> .has_full_3lvl_ppgtt
>
> Also add a new field, full_ppgtt_bits, that defines the actual
> address range. This gives us more flexibility and will work for
> cases where we have platforms with different address ranges but
> share the same page walk levels.
>
> Signed-off-by: Bob Paauwe
> CC: Rodrigo Vivi
> CC: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4 +--
> drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 34
> +---
> drivers/gpu/drm/i915/i915_params.c | 3 ++-
> drivers/gpu/drm/i915/i915_pci.c | 17 +++-
> drivers/gpu/drm/i915/intel_device_info.h | 7 +++--
> drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 2 +-
> drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 ++
> 11 files changed, 45 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e5b9d3c77139..b9f7903e60d1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2569,8 +2569,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>
> #define USES_PPGTT(dev_priv) (i915_modparams.enable_ppgtt)
> -#define USES_FULL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
> -#define USES_FULL_48BIT_PPGTT(dev_priv)(i915_modparams.enable_ppgtt
> == 3)
> +#define USES_FULL_3LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
> +#define USES_FULL_4LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt == 3)
> #define HAS_PAGE_SIZES(dev_priv, sizes) ({ \
> GEM_BUG_ON((sizes) == 0); \
> ((sizes) & ~(dev_priv)->info.page_sizes) == 0; \
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index f15a039772db..a0dc3170b358 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -361,7 +361,7 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
> if (IS_ERR(ctx))
> return ctx;
>
> - if (USES_FULL_PPGTT(dev_priv)) {
> + if (USES_FULL_3LVL_PPGTT(dev_priv)) {
That is not an improvement. It really is a question of whether or not
full-ppgtt is enabled.
> struct i915_hw_ppgtt *ppgtt;
>
> ppgtt = i915_ppgtt_create(dev_priv, file_priv);
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index a926d7d47183..166f1ea1786f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2201,7 +2201,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> eb.flags = (unsigned int *)(eb.vma + args->buffer_count + 1);
>
> eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS;
> - if (USES_FULL_PPGTT(eb.i915))
> + if (USES_FULL_3LVL_PPGTT(eb.i915))
Again the same complaint.
I think you need to rethink the semantics carefully.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Explicitly mark Global GTT address spaces
Quoting Tvrtko Ursulin (2018-08-31 15:36:43)
> From: Tvrtko Ursulin
>
> So far we have been relying on vm->file pointer being NULL to declare
> something GGTT.
>
> This has the unfortunate consequence that the default kernel context is
> also declared GGTT and interferes with the following patch which wants to
> instantiate VMA's and execute requests against the kernel context.
>
> Change the is_ggtt test to use an explicit flag in struct address_space to
> solve this issue.
>
> Note that the bit used is free since there is an alignment hole in the
> struct.
>
> v2:
> * Mark mock ggtt.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
> drivers/gpu/drm/i915/i915_gem_gtt.h | 5 -
> drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 ++
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index d9d44639ba26..eb0e446d6482 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3604,6 +3604,8 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv)
> mutex_lock(_priv->drm.struct_mutex);
> i915_address_space_init(>vm, dev_priv);
>
> + ggtt->vm.is_ggtt = true;
> +
> /* Only VLV supports read-only GGTT mappings */
> ggtt->vm.has_read_only = IS_VALLEYVIEW(dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 01d83a943142..7e2af5f4f39b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -324,6 +324,9 @@ struct i915_address_space {
>
> struct pagestash free_pages;
>
> + /* Global GTT */
> + bool is_ggtt:1;
> +
> /* Some systems require uncached updates of the page directories */
> bool pt_kmap_wc:1;
>
> @@ -357,7 +360,7 @@ struct i915_address_space {
> I915_SELFTEST_DECLARE(bool scrub_64K);
> };
>
> -#define i915_is_ggtt(V) (!(V)->file)
> +#define i915_is_ggtt(vm) ((vm)->is_ggtt)
But it's so explicit!
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Rename full ppgtt configuration to be more generic
For ppgtt, what we're really interested in is the number of page
walk levels for each platform. Rename the device info fields to
reflect this:
.has_full_48b_ppgtt -> .has_full_4lvl_ppgtt
.has_full_ppgtt -> .has_full_3lvl_ppgtt
Also add a new field, full_ppgtt_bits, that defines the actual
address range. This gives us more flexibility and will work for
cases where we have platforms with different address ranges but
share the same page walk levels.
Signed-off-by: Bob Paauwe
CC: Rodrigo Vivi
CC: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 4 +--
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 34 +---
drivers/gpu/drm/i915/i915_params.c | 3 ++-
drivers/gpu/drm/i915/i915_pci.c | 17 +++-
drivers/gpu/drm/i915/intel_device_info.h | 7 +++--
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 2 +-
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 ++
11 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e5b9d3c77139..b9f7903e60d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2569,8 +2569,8 @@ intel_info(const struct drm_i915_private *dev_priv)
#define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
#define USES_PPGTT(dev_priv) (i915_modparams.enable_ppgtt)
-#define USES_FULL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
-#define USES_FULL_48BIT_PPGTT(dev_priv)(i915_modparams.enable_ppgtt ==
3)
+#define USES_FULL_3LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt >= 2)
+#define USES_FULL_4LVL_PPGTT(dev_priv) (i915_modparams.enable_ppgtt == 3)
#define HAS_PAGE_SIZES(dev_priv, sizes) ({ \
GEM_BUG_ON((sizes) == 0); \
((sizes) & ~(dev_priv)->info.page_sizes) == 0; \
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f15a039772db..a0dc3170b358 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -361,7 +361,7 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
if (IS_ERR(ctx))
return ctx;
- if (USES_FULL_PPGTT(dev_priv)) {
+ if (USES_FULL_3LVL_PPGTT(dev_priv)) {
struct i915_hw_ppgtt *ppgtt;
ppgtt = i915_ppgtt_create(dev_priv, file_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a926d7d47183..166f1ea1786f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2201,7 +2201,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
eb.flags = (unsigned int *)(eb.vma + args->buffer_count + 1);
eb.invalid_flags = __EXEC_OBJECT_UNKNOWN_FLAGS;
- if (USES_FULL_PPGTT(eb.i915))
+ if (USES_FULL_3LVL_PPGTT(eb.i915))
eb.invalid_flags |= EXEC_OBJECT_NEEDS_GTT;
reloc_cache_init(_cache, eb.i915);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4137af4bd8f5..15f957a6ae38 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -136,19 +136,19 @@ static inline void i915_ggtt_invalidate(struct
drm_i915_private *i915)
int intel_sanitize_enable_ppgtt(struct drm_i915_private *dev_priv,
int enable_ppgtt)
{
- bool has_full_ppgtt;
- bool has_full_48bit_ppgtt;
+ bool has_full_3lvl_ppgtt;
+ bool has_full_4lvl_ppgtt;
if (!dev_priv->info.has_aliasing_ppgtt)
return 0;
- has_full_ppgtt = dev_priv->info.has_full_ppgtt;
- has_full_48bit_ppgtt = dev_priv->info.has_full_48bit_ppgtt;
+ has_full_3lvl_ppgtt = dev_priv->info.has_full_3lvl_ppgtt;
+ has_full_4lvl_ppgtt = dev_priv->info.has_full_4lvl_ppgtt;
if (intel_vgpu_active(dev_priv)) {
/* GVT-g has no support for 32bit ppgtt */
- has_full_ppgtt = false;
- has_full_48bit_ppgtt =
intel_vgpu_has_full_48bit_ppgtt(dev_priv);
+ has_full_3lvl_ppgtt = false;
+ has_full_4lvl_ppgtt = intel_vgpu_has_full_48bit_ppgtt(dev_priv);
}
/*
@@ -161,10 +161,10 @@ int intel_sanitize_enable_ppgtt(struct drm_i915_private
*dev_priv,
if (enable_ppgtt == 1)
return 1;
- if (enable_ppgtt == 2 && has_full_ppgtt)
+ if (enable_ppgtt == 2 && has_full_3lvl_ppgtt)
return 2;
- if (enable_ppgtt == 3 && has_full_48bit_ppgtt)
+ if (enable_ppgtt == 3 && has_full_4lvl_ppgtt)
return 3;
/*
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Explicitly mark Global GTT address spaces
== Series Details ==
Series: drm/i915: Explicitly mark Global GTT address spaces
URL : https://patchwork.freedesktop.org/series/49018/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4749 -> Patchwork_10061 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49018/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10061 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_selftest@live_hangcheck:
fi-kbl-guc: PASS -> DMESG-FAIL (fdo#106947, fdo#107710)
igt@gem_exec_suspend@basic-s3:
{fi-kbl-soraka}:NOTRUN -> INCOMPLETE (fdo#107556, fdo#107774)
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
{fi-byt-clapper}: PASS -> FAIL (fdo#107362, fdo#103191)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107708, fdo#107602)
Possible fixes
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: FAIL (fdo#107336) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
fdo#107708 https://bugs.freedesktop.org/show_bug.cgi?id=107708
fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710
fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774
== Participating hosts (52 -> 47) ==
Additional (1): fi-kbl-soraka
Missing(6): fi-hsw-4770r fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4749 -> Patchwork_10061
CI_DRM_4749: 4a46c18fad0de38a78b4b0c848892de494324a17 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4616: 5800e46c6f851c370c944a7cb169e99657239f8d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10061: a97af16a4feebcee5d0076479ff281eba089ffc2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a97af16a4fee drm/i915: Explicitly mark Global GTT address spaces
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10061/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/21] drm/i915/guc: Make use of the SW counter field in the context descriptor
On 2018-08-30 16:15, Lis, Tomasz wrote:
On 2018-08-30 02:08, Lionel Landwerlin wrote:
On 29/08/2018 20:16, Michal Wajdeczko wrote:
The new context descriptor format contains two assignable fields:
the SW Context ID (technically 11 bits, but practically limited to 2032
entries due to some being reserved for future use by the GuC) and the
SW Counter (6 bits).
We don't want to limit ourselves too much in the maximum number of
concurrent contexts we want to allow, so ideally we want to employ
every possible bit available. Unfortunately, a further limitation in
the interface with the GuC means the combination of SW Context ID +
SW Counter has to be unique within the same engine class (as we use
the SW Context ID to index in the GuC stage descriptor pool, and the
Engine Class + SW Counter to index in the 2-dimensional lrc array).
This essentially means we need to somehow encode the engine instance.
Since the BSpec allows 6 bits for engine instance, we use the whole
SW counter for this task. If the limitation of 2032 maximum
simultaneous
contexts is too restrictive, we can always squeeze things a bit more
(3 extras bits for hw_id, 3 bits for instance) and things will still
work (Gen11 does not instance more than 8 engines of any class).
Another alternative would be to generate the hw_id per HW context
instead of per GEM context, but that has other problems (e.g. maximum
number of user-created contexts would be variable, no relationship
between a GuC principal descriptor and the proxy descriptor it uses,
...)
Bspec: 12254
Signed-off-by: Oscar Mateo
Signed-off-by: Rodrigo Vivi
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: Michel Thierry
Tested-by: Tomasz Lis
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
drivers/gpu/drm/i915/i915_gem_context.c | 5 -
drivers/gpu/drm/i915/i915_gem_context.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 12 +---
5 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index e5b9d3c..34f5495 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1866,14 +1866,21 @@ struct drm_i915_private {
struct llist_head free_list;
struct work_struct free_work;
- /* The hw wants to have a stable context identifier for the
+ /*
+ * The HW wants to have a stable context identifier for the
* lifetime of the context (for OA, PASID, faults, etc).
* This is limited in execlists to 21 bits.
+ * In enhanced execlist (GEN11+) this is limited to 11 bits
+ * (the SW Context ID field) but GuC limits it a bit further
+ * (11 bits - 16) due to some entries being reserved for
future
+ * use (so the firmware only supports a GuC stage descriptor
+ * pool of 2032 entries).
*/
struct ida hw_ida;
-#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
-#define MAX_GUC_CONTEXT_HW_ID (1 << 20) /* exclusive */
-#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
+#define MAX_CONTEXT_HW_ID (1 << 21) /* exclusive */
+#define MAX_GUC_CONTEXT_HW_ID (1 << 20) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID (1 << 11) /* exclusive */
+#define GEN11_MAX_CONTEXT_HW_ID_WITH_GUC (GEN11_MAX_CONTEXT_HW_ID -
16)
} contexts;
u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f15a039..e3b500c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -209,7 +209,10 @@ static int assign_hw_id(struct drm_i915_private
*dev_priv, unsigned *out)
unsigned int max;
if (INTEL_GEN(dev_priv) >= 11) {
- max = GEN11_MAX_CONTEXT_HW_ID;
+ if (USES_GUC_SUBMISSION(dev_priv))
+ max = GEN11_MAX_CONTEXT_HW_ID_WITH_GUC;
+ else
+ max = GEN11_MAX_CONTEXT_HW_ID;
} else {
/*
* When using GuC in proxy submission, GuC consumes the
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index 851dad6..4b87f5d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -154,6 +154,8 @@ struct i915_gem_context {
struct intel_ring *ring;
u32 *lrc_reg_state;
u64 lrc_desc;
+ u32 sw_context_id;
+ u32 sw_counter;
int pin_count;
const struct intel_context_ops *ops;
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index f232178..ea65d7b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3900,6 +3900,8 @@ enum {
#define GEN8_CTX_ID_WIDTH 21
#define GEN11_SW_CTX_ID_SHIFT 37
#define GEN11_SW_CTX_ID_WIDTH 11
+#define
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Reviewed perf cleanups
Quoting Patchwork (2018-08-13 11:00:57) > == Series Details == > > Series: Reviewed perf cleanups > URL : https://patchwork.freedesktop.org/series/48100/ > State : success > > == Summary == > > = CI Bug Log - changes from CI_DRM_4660_full -> Patchwork_9926_full = > > == Summary - SUCCESS == > > No regressions found. And pushed. Ta, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Explicitly mark Global GTT address spaces
== Series Details == Series: drm/i915: Explicitly mark Global GTT address spaces URL : https://patchwork.freedesktop.org/series/49018/ State : warning == Summary == $ dim checkpatch origin/drm-tip a97af16a4fee drm/i915: Explicitly mark Global GTT address spaces -:47: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #47: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:328: + bool is_ggtt:1; total: 0 errors, 1 warnings, 0 checks, 33 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Load DMC v1.07 on Icelake (rev2)
== Series Details ==
Series: Load DMC v1.07 on Icelake (rev2)
URL : https://patchwork.freedesktop.org/series/48773/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4749 -> Patchwork_10060 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10060 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10060, 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/48773/revisions/2/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_10060:
=== IGT changes ===
Warnings
igt@pm_rpm@basic-rte:
fi-icl-u: SKIP -> PASS +2
{igt@pm_rpm@module-reload}:
fi-hsw-4770r: PASS -> SKIP
== Known issues ==
Here are the changes found in Patchwork_10060 that come from known issues:
=== IGT changes ===
Issues hit
{igt@amdgpu/amd_prime@i915-to-amd}:
fi-bxt-j4205: SKIP -> INCOMPLETE (fdo#103927)
igt@drv_module_reload@basic-reload-inject:
fi-hsw-4770r: PASS -> DMESG-WARN (fdo#107425)
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
igt@gem_exec_suspend@basic-s3:
{fi-kbl-soraka}:NOTRUN -> INCOMPLETE (fdo#107556, fdo#107774)
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602, fdo#107708)
fi-bxt-j4205: PASS -> DMESG-FAIL (fdo#107712)
{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#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
fdo#107708 https://bugs.freedesktop.org/show_bug.cgi?id=107708
fdo#107712 https://bugs.freedesktop.org/show_bug.cgi?id=107712
fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774
== Participating hosts (52 -> 48) ==
Additional (1): fi-kbl-soraka
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4749 -> Patchwork_10060
CI_DRM_4749: 4a46c18fad0de38a78b4b0c848892de494324a17 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4616: 5800e46c6f851c370c944a7cb169e99657239f8d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10060: 66f1af546312a6716f0abb2017145bba52c032ff @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
66f1af546312 firmware/dmc/icl: load v1.07 on icelake.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10060/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 Decode memdev info and bandwidth and implemnt latency WA (rev4)
== Series Details == Series: Decode memdev info and bandwidth and implemnt latency WA (rev4) URL : https://patchwork.freedesktop.org/series/46481/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4748_full -> Patchwork_10058_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10058_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10058_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_10058_full: === IGT changes === Warnings igt@kms_draw_crc@draw-method-xrgb-mmap-wc-untiled: shard-snb: PASS -> SKIP igt@pm_rc6_residency@rc6-accuracy: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_10058_full that come from known issues: === IGT changes === Issues hit igt@gem_ppgtt@blt-vs-render-ctx0: shard-snb: NOTRUN -> INCOMPLETE (fdo#105411, fdo#106887) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_ctx_isolation@rcs0-s3: shard-kbl: INCOMPLETE (fdo#107556, fdo#103665) -> PASS igt@gem_exec_store@pages-blt: shard-snb: INCOMPLETE (fdo#105411) -> PASS igt@kms_cursor_crc@cursor-256x256-suspend: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-varying-size: shard-hsw: FAIL (fdo#103355) -> PASS fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#106887 https://bugs.freedesktop.org/show_bug.cgi?id=106887 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4748 -> Patchwork_10058 CI_DRM_4748: 6caeb081ceb9282503439565e7093c1032758289 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4613: 3f89d7b02dcf662e994c7135b13d52bc8e09a4ea @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10058: 268a50bd35d9781b263680138c19715a02b27c72 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10058/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Explicitly mark Global GTT address spaces
From: Tvrtko Ursulin
So far we have been relying on vm->file pointer being NULL to declare
something GGTT.
This has the unfortunate consequence that the default kernel context is
also declared GGTT and interferes with the following patch which wants to
instantiate VMA's and execute requests against the kernel context.
Change the is_ggtt test to use an explicit flag in struct address_space to
solve this issue.
Note that the bit used is free since there is an alignment hole in the
struct.
v2:
* Mark mock ggtt.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 -
drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 ++
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d9d44639ba26..eb0e446d6482 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3604,6 +3604,8 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv)
mutex_lock(_priv->drm.struct_mutex);
i915_address_space_init(>vm, dev_priv);
+ ggtt->vm.is_ggtt = true;
+
/* Only VLV supports read-only GGTT mappings */
ggtt->vm.has_read_only = IS_VALLEYVIEW(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 01d83a943142..7e2af5f4f39b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -324,6 +324,9 @@ struct i915_address_space {
struct pagestash free_pages;
+ /* Global GTT */
+ bool is_ggtt:1;
+
/* Some systems require uncached updates of the page directories */
bool pt_kmap_wc:1;
@@ -357,7 +360,7 @@ struct i915_address_space {
I915_SELFTEST_DECLARE(bool scrub_64K);
};
-#define i915_is_ggtt(V) (!(V)->file)
+#define i915_is_ggtt(vm) ((vm)->is_ggtt)
static inline bool
i915_vm_is_48bit(const struct i915_address_space *vm)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c
b/drivers/gpu/drm/i915/selftests/mock_gtt.c
index a140ea5c3a7c..6ae418c76015 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c
@@ -118,6 +118,8 @@ void mock_init_ggtt(struct drm_i915_private *i915)
ggtt->vm.vma_ops.clear_pages = clear_pages;
i915_address_space_init(>vm, i915);
+
+ ggtt->vm.is_ggtt = true;
}
void mock_fini_ggtt(struct drm_i915_private *i915)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Avoid Gen10 watermark workarounds in Gen11
On Thu, Aug 23, 2018 at 08:59:44AM +0530, Karthik B S wrote:
> Check added to skip the watermark workarounds intended for Gen10 and
> below platforms in Gen11.
This seems a bit ambiguous for me, could you please improve the commit
message a bit?
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/intel_pm.c | 39 +++
> 1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d99e5fa..1928fe0 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4677,28 +4677,35 @@ 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);
> -
> - /* Display WA #1126: skl,bxt,kbl,glk */
> - if (level >= 1 && level <= 7) {
> - if (wp->y_tiled) {
> + if (INTEL_GEN(dev_priv) < 11) {
> + /* Display WA #1125: skl,bxt,kbl,glk */
> + if (level == 0 && wp->rc_surface)
> 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.
> - */
> + /*
> + * 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 (level >= 1 && level <= 7) {
> if (result_prev->plane_res_b > res_blocks)
> res_blocks = result_prev->plane_res_b;
Everything above makes sense and I checked against spec and it is right.
> + if (result_prev->plane_res_l > res_lines)
> + res_lines = result_prev->plane_res_l;
My on;y concern here is with this line...
This seems a new addition that if needed needs to come in a
separated patch with its own justification.
Sorry for taking so long to review it.
Thanks,
Rodrigo.
> }
>
> if (INTEL_GEN(dev_priv) >= 11) {
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Stop caching __drm_device_id
On Fri, Aug 31, 2018 at 01:18:53PM +0100, Chris Wilson wrote:
> In a multi-device system there is no guarantee that the fd being probed
> in intel_get_drm_devid() is the same as was opened earlier. Any cache
> may outlive the fd, so is frought with lifetime issues. The primary
> reason for caching the devid was to avoid extra ioctls in the
> dmesg/strace, but hopefully all users now grab the id in their fixture
> and not inside every function.
>
> Signed-off-by: Chris Wilson
> Cc: Katarzyna Dec
Reviewed-by: Rodrigo Vivi
> ---
> lib/drmtest.c | 3 ---
> lib/intel_chipset.c | 14 +-
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index fae6f86f2..ecb535f5d 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -75,8 +75,6 @@
> * and [batchbuffer](igt-gpu-tools-intel-batchbuffer.html) libraries as
> dependencies.
> */
>
> -uint16_t __drm_device_id;
> -
> static int __get_drm_device_name(int fd, char *name)
> {
> drm_version_t version;
> @@ -142,7 +140,6 @@ static bool has_known_intel_chipset(int fd)
> if (!intel_gen(devid))
> return false;
>
> - __drm_device_id = devid;
> return true;
> }
>
> diff --git a/lib/intel_chipset.c b/lib/intel_chipset.c
> index ab35fa70c..4748a3fb8 100644
> --- a/lib/intel_chipset.c
> +++ b/lib/intel_chipset.c
> @@ -112,8 +112,6 @@ intel_get_pci_device(void)
> return pci_dev;
> }
>
> -extern uint16_t __drm_device_id;
> -
> /**
> * intel_get_drm_devid:
> * @fd: open i915 drm file descriptor
> @@ -127,16 +125,22 @@ extern uint16_t __drm_device_id;
> uint32_t
> intel_get_drm_devid(int fd)
> {
> + struct drm_i915_getparam gp;
> const char *override;
> + int devid = 0;
>
> igt_assert(is_i915_device(fd));
> - igt_assert(__drm_device_id);
>
> override = getenv("INTEL_DEVID_OVERRIDE");
> if (override)
> return strtol(override, NULL, 0);
> - else
> - return __drm_device_id;
> +
> + memset(, 0, sizeof(gp));
> + gp.param = I915_PARAM_CHIPSET_ID;
> + gp.value =
> + ioctl(fd, DRM_IOCTL_I915_GETPARAM, , sizeof(gp));
> +
> + return devid;
> }
>
> /**
> --
> 2.19.0.rc1
>
> ___
> 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] [igt-dev] [PATCH] [intel-gfx] [PATCH i-g-t] tests/pm_backlight.c : Brightness test with DPMS and System suspend.
On Fri, Aug 31, 2018 at 12:39:05AM -0400, Jyoti Yadav wrote:
> From: Jyoti
>
> BIOS programs few of PWM related registers during initial boot.
> But during System suspend those registers are cleared.
> This test aim to check whether display programs those registers properly after
> system resume.
> Also checks brightness programming during DPMS ON/OFF cycle to check backlight
> programming is done properly from display side.
>
> v2 : Optimize the code to avoid code redundancy. (Rodrigo)
>
> Signed-off-by: Jyoti Yadav
Reviewed-by: Rodrigo Vivi
and pushed...
Thanks,
Rodrigo.
> ---
> tests/pm_backlight.c | 30 --
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/tests/pm_backlight.c b/tests/pm_backlight.c
> index a695f90..8b5c79d 100644
> --- a/tests/pm_backlight.c
> +++ b/tests/pm_backlight.c
> @@ -47,6 +47,7 @@ struct context {
> #define FADESPEED 100 /* milliseconds between steps */
>
> IGT_TEST_DESCRIPTION("Basic backlight sysfs test");
> +static int8_t *pm_data = NULL;
>
> static int backlight_read(int *result, const char *fname)
> {
> @@ -150,19 +151,38 @@ static void test_fade(struct context *context)
> nanosleep(, NULL);
> }
> }
> +static void test_fade_with_dpms(struct context *context, igt_output_t
> *output)
> +{
> + bool has_runtime_pm;
> + has_runtime_pm = igt_setup_runtime_pm();
> + igt_info("Runtime PM support: %d\n", has_runtime_pm);
> + igt_assert(has_runtime_pm);
> + kmstest_set_connector_dpms(output->display->drm_fd,
> output->config.connector, DRM_MODE_DPMS_OFF);
> + igt_assert(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED));
> + kmstest_set_connector_dpms(output->display->drm_fd,
> output->config.connector, DRM_MODE_DPMS_ON);
> + igt_assert(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_ACTIVE));
> + test_fade(context);
> +}
> +static void test_fade_with_suspend(struct context *context, igt_output_t
> *output)
> +{
> + kmstest_set_connector_dpms(output->display->drm_fd,
> output->config.connector, DRM_MODE_DPMS_OFF);
> + igt_assert(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED));
> + igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
> + test_fade(context);
> +}
>
> igt_main
> {
> struct context context = {0};
> int old;
> igt_display_t display;
> + igt_output_t *output;
> struct igt_fb fb;
>
> igt_skip_on_simulation();
>
> igt_fixture {
> enum pipe pipe;
> - igt_output_t *output;
> bool found = false;
> char full_name[32] = {};
> char *name;
> @@ -187,7 +207,6 @@ igt_main
> for_each_pipe_with_valid_output(, pipe, output) {
> if (strcmp(name + 6, output->name))
> continue;
> -
> found = true;
> break;
> }
> @@ -205,6 +224,7 @@ igt_main
> igt_plane_set_fb(primary, );
>
> igt_display_commit2(, display.is_atomic ? COMMIT_ATOMIC
> : COMMIT_LEGACY);
> + pm_data = igt_pm_enable_sata_link_power_management();
> }
>
> igt_subtest("basic-brightness")
> @@ -213,6 +233,10 @@ igt_main
> test_bad_brightness();
> igt_subtest("fade")
> test_fade();
> + igt_subtest("fade_with_dpms")
> + test_fade_with_dpms(, output);
> + igt_subtest("fade_with_suspend")
> + test_fade_with_suspend(, output);
>
> igt_fixture {
> /* Restore old brightness */
> @@ -220,6 +244,8 @@ igt_main
>
> igt_display_fini();
> igt_remove_fb(display.drm_fd, );
> + igt_pm_restore_sata_link_power_management(pm_data);
> + free(pm_data);
> close(display.drm_fd);
> }
> }
> --
> 1.9.1
>
> ___
> 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] ✓ Fi.CI.IGT: success for drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL. (rev6)
On Fri, Aug 31, 2018 at 08:00:41AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL. (rev6) > URL : https://patchwork.freedesktop.org/series/48803/ > State : success Pushed to -dinq thanks for the patch and review. I also added the update request to BSpec about units for the offset field. > > == Summary == > > = CI Bug Log - changes from CI_DRM_4745_full -> Patchwork_10057_full = > > == Summary - WARNING == > > Minor unknown changes coming with Patchwork_10057_full need to be verified > manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_10057_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_10057_full: > > === IGT changes === > > Warnings > > igt@kms_concurrent@pipe-b: > shard-snb: SKIP -> PASS +1 > > igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled: > shard-snb: PASS -> SKIP +1 > > > == Known issues == > > Here are the changes found in Patchwork_10057_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: > shard-hsw: PASS -> FAIL (fdo#105767) > > igt@kms_cursor_legacy@cursor-vs-flip-toggle: > shard-hsw: PASS -> FAIL (fdo#103355) > > > Possible fixes > > igt@drv_suspend@shrink: > shard-hsw: INCOMPLETE (fdo#106886, fdo#103540) -> PASS > shard-apl: INCOMPLETE (fdo#106886, fdo#103927) -> PASS > shard-glk: FAIL (fdo#106886) -> PASS > > igt@gem_ppgtt@blt-vs-render-ctxn: > shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS > > igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > shard-glk: FAIL (fdo#105363) -> PASS +1 > > > fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 > fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 > fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 > fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 > fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 > fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 > fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 > fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 > > > == Participating hosts (5 -> 5) == > > No changes in participating hosts > > > == Build changes == > > * Linux: CI_DRM_4745 -> Patchwork_10057 > > CI_DRM_4745: 4ddf5e7833fae7268e674ddea403a24b36c8337d @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4612: e39e09910fc8e369e24f6a0cabaeb9356dbfae08 @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_10057: 225ce5d7d0c64e3c963e105a4e8d05d4533539fe @ > git://anongit.freedesktop.org/gfx-ci/linux > piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ > git://anongit.freedesktop.org/piglit > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10057/shards.html > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/kms_vblank: Test if we have functional rpm before testing
On Fri, Aug 31, 2018 at 04:30:31PM +0300, Imre Deak wrote: > On Fri, Aug 31, 2018 at 02:08:13PM +0100, Chris Wilson wrote: > > We want to test that provoking a vblank interrupt works correctly after > > waking up from runtime-pm. First though, we must wait for the device to > > enter runtime-suspend. If the device cannot, e.g. we haven't enabled the > > DMC firmware, the test should skip because our external requirements are > > not met. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107768 > > Signed-off-by: Chris Wilson > > Cc: Imre Deak > > Signed-off-by: Imre Deak I mean Reviewed-by: Imre Deak > > > --- > > tests/kms_vblank.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c > > index 508c0fa03..b3cd2d93c 100644 > > --- a/tests/kms_vblank.c > > +++ b/tests/kms_vblank.c > > @@ -352,7 +352,7 @@ static void vblank_ts_cont(data_t *data, int fd, int > > nchildren) > > } > > > > if (data->flags & RPM) > > - > > igt_assert(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED)); > > + > > igt_require(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED)); > > > > if (data->flags & SUSPEND) > > igt_system_suspend_autoresume(SUSPEND_STATE_MEM, > > -- > > 2.19.0.rc1 > > > ___ > 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] [PATCH i-g-t] tests/kms_vblank: Test if we have functional rpm before testing
On Fri, Aug 31, 2018 at 02:08:13PM +0100, Chris Wilson wrote: > We want to test that provoking a vblank interrupt works correctly after > waking up from runtime-pm. First though, we must wait for the device to > enter runtime-suspend. If the device cannot, e.g. we haven't enabled the > DMC firmware, the test should skip because our external requirements are > not met. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107768 > Signed-off-by: Chris Wilson > Cc: Imre Deak Signed-off-by: Imre Deak > --- > tests/kms_vblank.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c > index 508c0fa03..b3cd2d93c 100644 > --- a/tests/kms_vblank.c > +++ b/tests/kms_vblank.c > @@ -352,7 +352,7 @@ static void vblank_ts_cont(data_t *data, int fd, int > nchildren) > } > > if (data->flags & RPM) > - > igt_assert(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED)); > + > igt_require(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED)); > > if (data->flags & SUSPEND) > igt_system_suspend_autoresume(SUSPEND_STATE_MEM, > -- > 2.19.0.rc1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/kms_vblank: Test if we have functional rpm before testing
We want to test that provoking a vblank interrupt works correctly after waking up from runtime-pm. First though, we must wait for the device to enter runtime-suspend. If the device cannot, e.g. we haven't enabled the DMC firmware, the test should skip because our external requirements are not met. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107768 Signed-off-by: Chris Wilson Cc: Imre Deak --- tests/kms_vblank.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c index 508c0fa03..b3cd2d93c 100644 --- a/tests/kms_vblank.c +++ b/tests/kms_vblank.c @@ -352,7 +352,7 @@ static void vblank_ts_cont(data_t *data, int fd, int nchildren) } if (data->flags & RPM) - igt_assert(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED)); + igt_require(igt_wait_for_pm_status(IGT_RUNTIME_PM_STATUS_SUSPENDED)); if (data->flags & SUSPEND) igt_system_suspend_autoresume(SUSPEND_STATE_MEM, -- 2.19.0.rc1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reduce context HW ID lifetime
Quoting Tvrtko Ursulin (2018-08-30 17:23:43)
>
> On 30/08/2018 11:24, Chris Wilson wrote:
> > +static int steal_hw_id(struct drm_i915_private *i915)
> > +{
> > + struct i915_gem_context *ctx, *cn;
> > + LIST_HEAD(pinned);
> > + int id = -ENOSPC;
> > +
> > + lockdep_assert_held(>contexts.mutex);
> > +
> > + list_for_each_entry_safe(ctx, cn,
> > + >contexts.hw_id_list, hw_id_link) {
> > + if (atomic_read(>pin_hw_id)) {
> > + list_move_tail(>hw_id_link, );
> > + continue;
> > + }
> > +
> > + GEM_BUG_ON(!ctx->hw_id); /* perma-pinned kernel context */
> > + list_del_init(>hw_id_link);
> > + id = ctx->hw_id;
> > + break;
> > + }
> > +
> > + list_splice_tail(, >contexts.hw_id_list);
>
> Put a comment what is this code doing please. Trying to create some sort
> of LRU order?
LRSearched. Same as the shrinker, and eviction code if you would also
review that ;)
>
> > + return id;
> > +}
> > +
> > +static int assign_hw_id(struct drm_i915_private *i915, unsigned int *out)
> > +{
> > + int ret;
> > +
> > + lockdep_assert_held(>contexts.mutex);
> > +
> > + ret = new_hw_id(i915, GFP_KERNEL | __GFP_RETRY_MAYFAIL |
> > __GFP_NOWARN);
> > + if (unlikely(ret < 0)) {
> > + ret = steal_hw_id(i915);
> > + if (ret < 0) /* once again for the correct erro code */
>
> errno
>
> > + ret = new_hw_id(i915, GFP_KERNEL);
>
> Hmm.. shouldn't you try GFP_KERNEL before attempting to steal? Actually
> I think you should branch based on -ENOSPC (steal) vs -ENOMEM (retry
> with GFP_KERNEL). Which would actually mean something like:
I was applying the same strategy as we use elsewhere. Penalise any
driver cache before hitting reclaim.
I think that is fair from an application of soft backpressure point of
view. (Lack of backpressure is probably a sore point for many.)
> > - ret = ida_simple_get(_priv->contexts.hw_ida,
> > - 0, max, GFP_KERNEL);
>
> Although now that I see this I am struggling not to say the change to
> try a lighter weight allocation strategy first (gfp may fail) needs to
> be split out to a separate patch.
Pardon? I appear to suddenly be hard of hearing.
The patch was all about the steal_hw_id().
> > - if (ret < 0) {
> > - /* Contexts are only released when no longer active.
> > - * Flush any pending retires to hopefully release some
> > - * stale contexts and try again.
> > - */
> > - i915_retire_requests(dev_priv);
> > - ret = ida_simple_get(_priv->contexts.hw_ida,
> > - 0, max, GFP_KERNEL);
> > - if (ret < 0)
> > - return ret;
> > - }
> > -
> > - *out = ret;
> > - return 0;
> > -}
> > -
> > static u32 default_desc_template(const struct drm_i915_private *i915,
> >const struct i915_hw_ppgtt *ppgtt)
> > {
> > @@ -276,12 +324,6 @@ __create_hw_context(struct drm_i915_private *dev_priv,
> > if (ctx == NULL)
> > return ERR_PTR(-ENOMEM);
> >
> > - ret = assign_hw_id(dev_priv, >hw_id);
> > - if (ret) {
> > - kfree(ctx);
> > - return ERR_PTR(ret);
> > - }
> > -
> > kref_init(>ref);
> > list_add_tail(>link, _priv->contexts.list);
> > ctx->i915 = dev_priv;
> > @@ -295,6 +337,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
> >
> > INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
> > INIT_LIST_HEAD(>handles_list);
> > + INIT_LIST_HEAD(>hw_id_link);
> >
> > /* Default context will never have a file_priv */
> > ret = DEFAULT_CONTEXT_HANDLE;
> > @@ -421,15 +464,35 @@ i915_gem_context_create_gvt(struct drm_device *dev)
> > return ctx;
> > }
> >
> > +static void
> > +destroy_kernel_context(struct i915_gem_context **ctxp)
> > +{
> > + struct i915_gem_context *ctx;
> > +
> > + /* Keep the context ref so that we can free it immediately ourselves
> > */
> > + ctx = i915_gem_context_get(fetch_and_zero(ctxp));
> > + GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
> > +
> > + context_close(ctx);
> > + i915_gem_context_free(ctx);
> > +}
> > +
> > struct i915_gem_context *
> > i915_gem_context_create_kernel(struct drm_i915_private *i915, int prio)
> > {
> > struct i915_gem_context *ctx;
> > + int err;
> >
> > ctx = i915_gem_create_context(i915, NULL);
> > if (IS_ERR(ctx))
> > return ctx;
> >
> > + err = i915_gem_context_pin_hw_id(ctx);
> > + if (err) {
> > + destroy_kernel_context();
> > + return ERR_PTR(err);
> > + }
> > +
> > i915_gem_context_clear_bannable(ctx);
> > ctx->sched.priority = prio;
> > ctx->ring_size = PAGE_SIZE;
> > @@
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix context RPCS programming
== Series Details ==
Series: drm/i915/icl: Fix context RPCS programming
URL : https://patchwork.freedesktop.org/series/49005/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4748 -> Patchwork_10059 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49005/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10059 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614)
{fi-byt-clapper}: PASS -> FAIL (fdo#103167)
Possible fixes
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: FAIL (fdo#107336) -> PASS
{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#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4748 -> Patchwork_10059
CI_DRM_4748: 6caeb081ceb9282503439565e7093c1032758289 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4613: 3f89d7b02dcf662e994c7135b13d52bc8e09a4ea @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10059: 8b03edf949e3c9c6d97154e40c11f1f0d2a1aec7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8b03edf949e3 drm/i915/icl: Fix context RPCS programming
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10059/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] lib: Stop caching __drm_device_id
In a multi-device system there is no guarantee that the fd being probed
in intel_get_drm_devid() is the same as was opened earlier. Any cache
may outlive the fd, so is frought with lifetime issues. The primary
reason for caching the devid was to avoid extra ioctls in the
dmesg/strace, but hopefully all users now grab the id in their fixture
and not inside every function.
Signed-off-by: Chris Wilson
Cc: Katarzyna Dec
---
lib/drmtest.c | 3 ---
lib/intel_chipset.c | 14 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index fae6f86f2..ecb535f5d 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -75,8 +75,6 @@
* and [batchbuffer](igt-gpu-tools-intel-batchbuffer.html) libraries as
dependencies.
*/
-uint16_t __drm_device_id;
-
static int __get_drm_device_name(int fd, char *name)
{
drm_version_t version;
@@ -142,7 +140,6 @@ static bool has_known_intel_chipset(int fd)
if (!intel_gen(devid))
return false;
- __drm_device_id = devid;
return true;
}
diff --git a/lib/intel_chipset.c b/lib/intel_chipset.c
index ab35fa70c..4748a3fb8 100644
--- a/lib/intel_chipset.c
+++ b/lib/intel_chipset.c
@@ -112,8 +112,6 @@ intel_get_pci_device(void)
return pci_dev;
}
-extern uint16_t __drm_device_id;
-
/**
* intel_get_drm_devid:
* @fd: open i915 drm file descriptor
@@ -127,16 +125,22 @@ extern uint16_t __drm_device_id;
uint32_t
intel_get_drm_devid(int fd)
{
+ struct drm_i915_getparam gp;
const char *override;
+ int devid = 0;
igt_assert(is_i915_device(fd));
- igt_assert(__drm_device_id);
override = getenv("INTEL_DEVID_OVERRIDE");
if (override)
return strtol(override, NULL, 0);
- else
- return __drm_device_id;
+
+ memset(, 0, sizeof(gp));
+ gp.param = I915_PARAM_CHIPSET_ID;
+ gp.value =
+ ioctl(fd, DRM_IOCTL_I915_GETPARAM, , sizeof(gp));
+
+ return devid;
}
/**
--
2.19.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl: Fix context RPCS programming
From: Tvrtko Ursulin
There are two issues with the current RPCS programming for Icelake:
Expansion of the slice count bitfield has been missed, as well as the
required programming workaround for the subslice count bitfield size
limitation.
1)
Bitfield width for configuring the active slice count has grown so we need
to program the GEN8_R_PWR_CLK_STATE accordingly.
Current code was always requesting eight times the number of slices (due
writting to a bitfield starting three bits higher than it should). These
requests were luckily a) capped by the hardware to the available number of
slices, and b) we haven't yet exported the code to ask for reduced slice
configurations.
Due both of the above there was no impact from this incorrect programming
but we should still fix it.
2)
Due subslice count bitfield being only three bits wide and furthermore
capped to a maximum documented value of four, special programming
workaround is needed to enable more than four subslices.
With this programming driver has to consider the GT configuration as
2x4x8, while the hardware internally translates this to 1x8x8.
A limitation stemming from this is that either a subslice count between
one and four can be selected, or a subslice count equaling the total
number of subslices in all selected slices. In other words, odd subslice
counts greater than four are impossible, as are odd subslice counts
greater than a single slice subslice count.
This also had no impact in the current code base due breakage from 1)
always reqesting more than one slice.
While fixing this we also add some asserts to flag up any future bitfield
overflows.
Signed-off-by: Tvrtko Ursulin
Bspec: 12247
Reported-by: tony...@intel.com
Suggested-by: Lionel Landwerlin
Cc: Lionel Landwerlin
Cc: tony...@intel.com
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_lrc.c | 89 +++-
2 files changed, 78 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f2321785cbd6..09bc8e730ee1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -344,6 +344,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_RPCS_S_CNT_ENABLE (1 << 18)
#define GEN8_RPCS_S_CNT_SHIFT15
#define GEN8_RPCS_S_CNT_MASK (0x7 << GEN8_RPCS_S_CNT_SHIFT)
+#define GEN11_RPCS_S_CNT_SHIFT 12
+#define GEN11_RPCS_S_CNT_MASK(0x3f << GEN11_RPCS_S_CNT_SHIFT)
#define GEN8_RPCS_SS_CNT_ENABLE (1 << 11)
#define GEN8_RPCS_SS_CNT_SHIFT 8
#define GEN8_RPCS_SS_CNT_MASK(0x7 << GEN8_RPCS_SS_CNT_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f8ceb9c99dd6..323c46319cb8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2480,6 +2480,9 @@ int logical_xcs_ring_init(struct intel_engine_cs *engine)
static u32
make_rpcs(struct drm_i915_private *dev_priv)
{
+ bool subslice_pg = INTEL_INFO(dev_priv)->sseu.has_subslice_pg;
+ u8 slices = hweight8(INTEL_INFO(dev_priv)->sseu.slice_mask);
+ u8 subslices = hweight8(INTEL_INFO(dev_priv)->sseu.subslice_mask[0]);
u32 rpcs = 0;
/*
@@ -2489,6 +2492,38 @@ make_rpcs(struct drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) < 9)
return 0;
+ /*
+* Since the SScount bitfield in GEN8_R_PWR_CLK_STATE is only three bits
+* wide and Icelake has up to eight subslices, specfial programming is
+* needed in order to correctly enable all subslices.
+*
+* According to documentation software must consider the configuration
+* as 2x4x8 and hardware will translate this to 1x8x8.
+*
+* Furthemore, even though SScount is three bits, maximum documented
+* value for it is four. From this some rules/restrictions follow:
+*
+* 1.
+* If enabled subslice count is greater than four, two whole slices must
+* be enabled instead.
+*
+* 2.
+* When more than one slice is enabled, hardware ignores the subslice
+* count altogether.
+*
+* From these restrictions it follows that it is not possible to enable
+* a count of subslices between the SScount maximum of four restriction,
+* and the maximum available number on a particular SKU. Either all
+* subslices are enabled, or a count between one and four on the first
+* slice.
+*/
+ if (IS_GEN11(dev_priv) && slices == 1 && subslices >= 4) {
+ GEM_BUG_ON(subslices & 1);
+
+ subslice_pg = false;
+ slices *= 2;
+ }
+
/*
* Starting in Gen9, render power gating can leave
* slice/subslice/EU in a partially enabled state. We
@@ -2496,24 +2531,52 @@ make_rpcs(struct
[Intel-gfx] ✓ Fi.CI.BAT: success for Decode memdev info and bandwidth and implemnt latency WA (rev4)
== Series Details ==
Series: Decode memdev info and bandwidth and implemnt latency WA (rev4)
URL : https://patchwork.freedesktop.org/series/46481/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4748 -> Patchwork_10058 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/46481/revisions/4/mbox/
== Known issues ==
Here are the changes found in Patchwork_10058 that come from known issues:
=== IGT changes ===
Issues hit
{igt@amdgpu/amd_basic@userptr}:
{fi-kbl-8809g}: PASS -> INCOMPLETE (fdo#107402)
{igt@pm_rpm@module-reload}:
fi-cnl-psr: PASS -> WARN (fdo#107602, fdo#107708)
Possible fixes
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS
{igt@kms_psr@primary_page_flip}:
fi-cnl-psr: FAIL (fdo#107336) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
fdo#107402 https://bugs.freedesktop.org/show_bug.cgi?id=107402
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
fdo#107708 https://bugs.freedesktop.org/show_bug.cgi?id=107708
== Participating hosts (53 -> 48) ==
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4748 -> Patchwork_10058
CI_DRM_4748: 6caeb081ceb9282503439565e7093c1032758289 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4613: 3f89d7b02dcf662e994c7135b13d52bc8e09a4ea @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10058: 268a50bd35d9781b263680138c19715a02b27c72 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
268a50bd35d9 drm/i915/kbl+: Enable IPC only for symmetric memory configurations
9968070f860e drm/i915/skl+: don't trust IPC value set by BIOS
08094101d869 drm/i915: Implement 16GB dimm wa for latency level-0
bc3e164750dd drm/i915/skl+: Decode memory bandwidth and parameters
441057f30f45 drm/i915/bxt: Decode memory bandwidth and parameters
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10058/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Decode memdev info and bandwidth and implemnt latency WA (rev4)
== Series Details == Series: Decode memdev info and bandwidth and implemnt latency WA (rev4) URL : https://patchwork.freedesktop.org/series/46481/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/bxt: Decode memory bandwidth and parameters -drivers/gpu/drm/i915/selftests/../i915_drv.h:3687:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3698:16: warning: expression using sizeof(void) Commit: drm/i915/skl+: Decode memory bandwidth and parameters +drivers/gpu/drm/i915/i915_drv.c:1169:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1169:35: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3698:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3706:16: warning: expression using sizeof(void) Commit: drm/i915: Implement 16GB dimm wa for latency level-0 -drivers/gpu/drm/i915/selftests/../i915_drv.h:3706:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3709:16: warning: expression using sizeof(void) Commit: drm/i915/skl+: don't trust IPC value set by BIOS Okay! Commit: drm/i915/kbl+: Enable IPC only for symmetric memory configurations -drivers/gpu/drm/i915/selftests/../i915_drv.h:3709:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3710:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Decode memdev info and bandwidth and implemnt latency WA (rev4)
== Series Details == Series: Decode memdev info and bandwidth and implemnt latency WA (rev4) URL : https://patchwork.freedesktop.org/series/46481/ State : warning == Summary == $ dim checkpatch origin/drm-tip 441057f30f45 drm/i915/bxt: Decode memory bandwidth and parameters -:162: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/384 #162: FILE: drivers/gpu/drm/i915/i915_drv.h:1948: + bool valid; total: 0 errors, 0 warnings, 1 checks, 182 lines checked bc3e164750dd drm/i915/skl+: Decode memory bandwidth and parameters 08094101d869 drm/i915: Implement 16GB dimm wa for latency level-0 -:116: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/384 #116: FILE: drivers/gpu/drm/i915/i915_drv.h:1949: + bool valid_dimm; -:117: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/384 #117: FILE: drivers/gpu/drm/i915/i915_drv.h:1950: + bool is_16gb_dimm; -:125: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/384 #125: FILE: drivers/gpu/drm/i915/i915_drv.h:2179: + bool is_16gb_dimm; total: 0 errors, 0 warnings, 3 checks, 107 lines checked 9968070f860e drm/i915/skl+: don't trust IPC value set by BIOS 268a50bd35d9 drm/i915/kbl+: Enable IPC only for symmetric memory configurations -:82: CHECK:BOOL_MEMBER: Avoid using bool structure members because of possible alignment issues - see: https://lkml.org/lkml/2017/11/21/384 #82: FILE: drivers/gpu/drm/i915/i915_drv.h:1958: + bool symmetric_memory; total: 0 errors, 0 warnings, 1 checks, 67 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 2/2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.
On Fri, Aug 31, 2018 at 07:24:48AM +, Lisovskiy, Stanislav wrote: > On Thu, 2018-08-30 at 11:15 -0700, Dhinakaran Pandiyan wrote: > > On Thu, 2018-08-30 at 13:57 +0100, Lisovskiy, Stanislav wrote: > > > On Wed, 2018-08-29 at 12:16 -0700, Dhinakaran Pandiyan wrote: > > > > > > > > On Wed, 2018-08-29 at 21:10 +0300, Ville Syrjälä wrote: > > > > > On Wed, Aug 29, 2018 at 02:28:47PM +0300, Stanislav Lisovskiy > > > > > wrote: > > > > > > PLANE_CTL_FORMAT_AYUV is already supported, according to > > > > > > hardware > > > > > > specification. > > > > > > > > > > > > v2: Edited commit message, removed redundant whitespaces. > > > > > > > > > > > > v3: Fixed fallthrough logic for the format switch cases. > > > > > > > > > > > > v4: Yet again fixed fallthrough logic, to reuse code from > > > > > > other > > > > > > case > > > > > > labels. > > > > > > > > > > > > v5: Started to use XYUV instead of AYUV, as we don't use > > > > > > alpha. > > > > Curious what the reason is. Is it because the hardware does not > > support > > alpha with this format? > > As I understood yes, this is a hardware limitation. > > > > > > > > > > > > > > > v6: Removed unneeded initializer for new XYUV format. > > > > > > > > > > > > v7: Added scaling support for DRM_FORMAT_XYUV > > > > > > > > I don't see yuv formats in skl_format_to_fourcc(), any idea why? > > > > > > Good point. I guess would be nice idea to add at least XYUV there > > > now. > > > I can add rest of the formats with a separate patch afterwards. > > > > Wonder if the expectation is BIOS not use yuv formats. Ville? > > I talked to Ville yesterday, I think that was basically what he said. Yes. Although I have this dream of full plane state readout (which we could then use for verification purposes at least), so adding the missing formats there would be a decent idea. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V4 3/5] drm/i915: Implement 16GB dimm wa for latency level-0
Memory with 16GB dimms require an increase of 1us in level-0 latency.
This patch implements the same.
Bspec: 4381
changes since V1:
- s/memdev_info/dram_info
- make skl_is_16gb_dimm pure function
Changes since V2:
- make is_16gb_dimm more generic
- rebase
Changes since V3:
- Simplify condition (Maarten)
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 33 +++--
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 10 ++
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e09e9ce8fadf..2bc74c01a0e5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1088,6 +1088,21 @@ static enum dram_rank skl_get_dimm_rank(u8 size, u32
rank)
return I915_DRAM_RANK_INVALID;
}
+static bool
+skl_is_16gb_dimm(enum dram_rank rank, u8 size, u8 width)
+{
+ if (rank == I915_DRAM_RANK_SINGLE && width == 8 && size == 16)
+ return true;
+ else if (rank == I915_DRAM_RANK_DUAL && width == 8 && size == 32)
+ return true;
+ else if (rank == SKL_DRAM_RANK_SINGLE && width == 16 && size == 8)
+ return true;
+ else if (rank == SKL_DRAM_RANK_DUAL && width == 16 && size == 16)
+ return true;
+
+ return false;
+}
+
static int
skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
{
@@ -1125,6 +1140,11 @@ skl_dram_get_channel_info(struct dram_channel_info *ch,
u32 val)
else
ch->rank = I915_DRAM_RANK_SINGLE;
+ ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.rank, ch->l_info.size,
+ ch->l_info.width) ||
+ skl_is_16gb_dimm(ch->s_info.rank, ch->s_info.size,
+ ch->s_info.width);
+
DRM_DEBUG_KMS("(size:width:rank) L(%dGB:X%d:%s) S(%dGB:X%d:%s)\n",
ch->l_info.size, ch->l_info.width,
ch->l_info.rank ? "dual" : "single",
@@ -1157,6 +1177,8 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
return -EINVAL;
}
+ dram_info->valid_dimm = true;
+
/*
* If any of the channel is single rank channel, worst case output
* will be same as if single rank memory, so consider single rank
@@ -1172,6 +1194,10 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
DRM_INFO("couldn't get memory rank information\n");
return -EINVAL;
}
+
+ if (ch0.is_16gb_dimm || ch1.is_16gb_dimm)
+ dram_info->is_16gb_dimm = true;
+
return 0;
}
@@ -1284,6 +1310,7 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
return -EINVAL;
}
+ dram_info->valid_dimm = true;
dram_info->valid = true;
return 0;
}
@@ -1296,6 +1323,8 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
int ret;
dram_info->valid = false;
+ dram_info->valid_dimm = false;
+ dram_info->is_16gb_dimm = false;
dram_info->rank = I915_DRAM_RANK_INVALID;
dram_info->bandwidth_kbps = 0;
dram_info->num_channels = 0;
@@ -1319,9 +1348,9 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
sprintf(bandwidth_str, "unknown");
DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
bandwidth_str, dram_info->num_channels);
- DRM_DEBUG_KMS("DRAM rank: %s rank\n",
+ DRM_DEBUG_KMS("DRAM rank: %s rank 16GB-dimm:%s\n",
(dram_info->rank == I915_DRAM_RANK_DUAL) ?
- "dual" : "single");
+ "dual" : "single", yesno(dram_info->is_16gb_dimm));
}
/**
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9195e99a6aba..fe08a883e39f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1946,6 +1946,8 @@ struct drm_i915_private {
struct dram_info {
bool valid;
+ bool valid_dimm;
+ bool is_16gb_dimm;
u8 num_channels;
enum dram_rank {
I915_DRAM_RANK_INVALID = 0,
@@ -2174,6 +2176,7 @@ struct dram_channel_info {
enum dram_rank rank;
} l_info, s_info;
enum dram_rank rank;
+ bool is_16gb_dimm;
};
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d99e5fabe93c..09463e3d7948 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2875,6 +2875,16 @@ static void intel_read_wm_latency(struct
drm_i915_private *dev_priv,
}
}
+ /*
+* WA Level-0 adjustment for 16GB
Re: [Intel-gfx] [REGRESSION][BISECTED] drm_atomic_helper_wait_for_flip_done *ERROR* [CRTC:69:pipe C] flip_done timed out
Found the bad commit: https://cgit.freedesktop.org/drm-tip/commit/?id=afb2c4437daeed2d0c49e246ad1ad4def5d913cd drm/i915/ddi: Push pipe clock enabling to encoders Hope this helps. If there is anything else I can provide plz let me know. Regards Dieter On Tue, Aug 28, 2018 at 06:51:31PM +0200, dmummenschanz at web.de wrote: > Hi, > > I have a Lenovo T470 notebook with a KBL (GT2) CPU connected to a docking > station with two IPS monitors connected. > According to xrandr the primary laptop screen is connected to eDP-1 and the > monitors are connected to DP-2-1 and DP-2-2. > > This setup worked fine until kernel 4.19-rc1. After booting into the > framebuffer console the screen connected to DP-2-2 won't come on. > > When I try to startx my system locks up! > > I've cranked the debug level up to drm.debug=0xe. I'm not an expert but this > looks suspicious: > ... > [4.465645] [drm:intel_mst_enable_dp [i915]] active links 2 > [4.465655] [drm:intel_dp_check_mst_status [i915]] got esi 02 00 00 > [4.466964] [drm:intel_mst_enable_dp [i915]] *ERROR* Timed out waiting for > ACT sent > [4.478043] [drm:drm_dp_check_act_status [drm_kms_helper]] failed to get > ACT bit 1 after 30 retries > > and later: > [ 14.669161] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] > *ERROR* [CRTC:69:pipe C] flip_done timed out > [ 14.669269] [drm:verify_connector_state.isra.86 [i915]] > [CONNECTOR:100:DP-3] > [ 14.669328] [drm:intel_atomic_commit_tail [i915]] [CRTC:55:pipe B] > > and finally after firing up X: > [ 17.741227] [drm:edp_panel_vdd_off_sync [i915]] Turning eDP port A VDD off > [ 17.741347] [drm:edp_panel_vdd_off_sync [i915]] PP_STATUS: 0x8008 > PP_CONTROL: 0x0007 > [ 24.909159] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] > *ERROR* [CRTC:69:pipe C] flip_done timed out > > Full dmesg is provided here: https://pastebin.com/nDwvQPy6 > > Xorg.log doesn't reveal anything interesting. The last line in the log before > freezing: > [73.632] (II) xfree86: Adding drm device (/dev/dri/card0) > > Full log: https://pastebin.com/9RaAYhjP > > This is what xrandr shows with kernel 4.18 (with 4.19 I can't get that far): > > https://pastebin.com/cYSf9CyS > > I've tried various settings like switching monitors or switching the > dockingstation nothing helps. > > Actually I've encountered this issue months earlier with drm-tip roughly > about the time it > got merged with 4.18-rc1. I've opened a but last month but it didn't draw any > attention: > > https://bugs.freedesktop.org/show_bug.cgi?id=107365 This email here has more info than the bug entry, could you please update there? > > Now infortunalely this regression has made it into mainline :(. > I'll be happy to provide more information or do more tests but for now I'm > out of ideas. :( I raised the priority there, but it would be really good if you could bisect since you can easily reproduce and knows a working point in time. Thanks, Rodrigo. > > Regards > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 5/5] drm/i915/kbl+: Enable IPC only for symmetric memory configurations
Op 24-08-18 om 11:32 schreef Mahesh Kumar:
> IPC may cause underflows if not used with dual channel symmetric
> memory configuration. Disable IPC for non symmetric configurations in
> affected platforms.
> Display WA #1141
>
> Changes Since V1:
> - Re-arrange the code.
> - update wrapper to return if memory is symmetric (Rodrigo)
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.c | 27 ++-
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 5 +
> 3 files changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 2bc74c01a0e5..61d756ae7bf0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1154,21 +1154,32 @@ skl_dram_get_channel_info(struct dram_channel_info
> *ch, u32 val)
> return 0;
> }
>
> +static bool
> +intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
> + struct dram_channel_info *ch0)
> +{
> + return (val_ch0 == val_ch1 &&
> + (ch0->s_info.size == 0 ||
> + (ch0->l_info.size == ch0->s_info.size &&
> + ch0->l_info.width == ch0->s_info.width &&
> + ch0->l_info.rank == ch0->s_info.rank)));
> +}
> +
> static int
> skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
> {
> struct dram_info *dram_info = _priv->dram_info;
> struct dram_channel_info ch0, ch1;
> - u32 val;
> + u32 val_ch0, val_ch1;
> int ret;
>
> - val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> - ret = skl_dram_get_channel_info(, val);
> + val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> + ret = skl_dram_get_channel_info(, val_ch0);
> if (ret == 0)
> dram_info->num_channels++;
>
> - val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> - ret = skl_dram_get_channel_info(, val);
> + val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> + ret = skl_dram_get_channel_info(, val_ch1);
> if (ret == 0)
> dram_info->num_channels++;
>
> @@ -1198,6 +1209,12 @@ skl_dram_get_channels_info(struct drm_i915_private
> *dev_priv)
> if (ch0.is_16gb_dimm || ch1.is_16gb_dimm)
> dram_info->is_16gb_dimm = true;
>
> + dev_priv->dram_info.symmetric_memory = intel_is_dram_symmetric(val_ch0,
> +val_ch1,
> +);
> +
> + DRM_DEBUG_KMS("memory configuration is %sSymmetric memory\n",
> + dev_priv->dram_info.symmetric_memory ? "" : "not ");
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6c432684c721..e7faa046f78a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1955,6 +1955,7 @@ struct drm_i915_private {
> I915_DRAM_RANK_DUAL
> } rank;
> u32 bandwidth_kbps;
> + bool symmetric_memory;
> } dram_info;
>
> struct i915_runtime_pm runtime_pm;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 77970e38d939..c27646fb4cec 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6124,6 +6124,11 @@ void intel_enable_ipc(struct drm_i915_private
> *dev_priv)
> if (IS_SKYLAKE(dev_priv))
> dev_priv->ipc_enabled = false;
>
> + /* Display WA #1141: SKL:all KBL:all CFL */
> + if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) &&
> + !dev_priv->dram_info.symmetric_memory)
> + dev_priv->ipc_enabled = false;
> +
> val = I915_READ(DISP_ARB_CTL2);
>
> if (dev_priv->ipc_enabled)
Patch series looks good with minor nit in 3/5 fixed.
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V3 3/5] drm/i915: Implement 16GB dimm wa for latency level-0
Op 24-08-18 om 11:32 schreef Mahesh Kumar:
> Memory with 16GB dimms require an increase of 1us in level-0 latency.
> This patch implements the same.
> Bspec: 4381
>
> changes since V1:
> - s/memdev_info/dram_info
> - make skl_is_16gb_dimm pure function
> Changes since V2:
> - make is_16gb_dimm more generic
> - rebase
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.c | 33 +++--
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_pm.c | 13 +
> 3 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e09e9ce8fadf..2bc74c01a0e5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1088,6 +1088,21 @@ static enum dram_rank skl_get_dimm_rank(u8 size, u32
> rank)
> return I915_DRAM_RANK_INVALID;
> }
>
> +static bool
> +skl_is_16gb_dimm(enum dram_rank rank, u8 size, u8 width)
> +{
> + if (rank == I915_DRAM_RANK_SINGLE && width == 8 && size == 16)
> + return true;
> + else if (rank == I915_DRAM_RANK_DUAL && width == 8 && size == 32)
> + return true;
> + else if (rank == SKL_DRAM_RANK_SINGLE && width == 16 && size == 8)
> + return true;
> + else if (rank == SKL_DRAM_RANK_DUAL && width == 16 && size == 16)
> + return true;
> +
> + return false;
> +}
> +
> static int
> skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
> {
> @@ -1125,6 +1140,11 @@ skl_dram_get_channel_info(struct dram_channel_info
> *ch, u32 val)
> else
> ch->rank = I915_DRAM_RANK_SINGLE;
>
> + ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.rank, ch->l_info.size,
> + ch->l_info.width) ||
> +skl_is_16gb_dimm(ch->s_info.rank, ch->s_info.size,
> + ch->s_info.width);
> +
> DRM_DEBUG_KMS("(size:width:rank) L(%dGB:X%d:%s) S(%dGB:X%d:%s)\n",
> ch->l_info.size, ch->l_info.width,
> ch->l_info.rank ? "dual" : "single",
> @@ -1157,6 +1177,8 @@ skl_dram_get_channels_info(struct drm_i915_private
> *dev_priv)
> return -EINVAL;
> }
>
> + dram_info->valid_dimm = true;
> +
> /*
>* If any of the channel is single rank channel, worst case output
>* will be same as if single rank memory, so consider single rank
> @@ -1172,6 +1194,10 @@ skl_dram_get_channels_info(struct drm_i915_private
> *dev_priv)
> DRM_INFO("couldn't get memory rank information\n");
> return -EINVAL;
> }
> +
> + if (ch0.is_16gb_dimm || ch1.is_16gb_dimm)
> + dram_info->is_16gb_dimm = true;
> +
> return 0;
> }
>
> @@ -1284,6 +1310,7 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
> return -EINVAL;
> }
>
> + dram_info->valid_dimm = true;
> dram_info->valid = true;
> return 0;
> }
> @@ -1296,6 +1323,8 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
> int ret;
>
> dram_info->valid = false;
> + dram_info->valid_dimm = false;
> + dram_info->is_16gb_dimm = false;
> dram_info->rank = I915_DRAM_RANK_INVALID;
> dram_info->bandwidth_kbps = 0;
> dram_info->num_channels = 0;
> @@ -1319,9 +1348,9 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
> sprintf(bandwidth_str, "unknown");
> DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
> bandwidth_str, dram_info->num_channels);
> - DRM_DEBUG_KMS("DRAM rank: %s rank\n",
> + DRM_DEBUG_KMS("DRAM rank: %s rank 16GB-dimm:%s\n",
> (dram_info->rank == I915_DRAM_RANK_DUAL) ?
> - "dual" : "single");
> + "dual" : "single", yesno(dram_info->is_16gb_dimm));
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0dfa0fdbbae2..6c432684c721 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1946,6 +1946,8 @@ struct drm_i915_private {
>
> struct dram_info {
> bool valid;
> + bool valid_dimm;
> + bool is_16gb_dimm;
> u8 num_channels;
> enum dram_rank {
> I915_DRAM_RANK_INVALID = 0,
> @@ -2174,6 +2176,7 @@ struct dram_channel_info {
> enum dram_rank rank;
> } l_info, s_info;
> enum dram_rank rank;
> + bool is_16gb_dimm;
> };
>
> static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d99e5fabe93c..9550e24ffc2f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2875,6 +2875,19 @@ static void intel_read_wm_latency(struct
>
Re: [Intel-gfx] [PATCH v4] drm/i915/selftests: Add a simple exerciser for suspend/hibernate
Quoting Chris Wilson (2018-08-31 10:09:00)
> Quoting Bartminski, Jakub (2018-08-31 10:01:57)
> > Looks good to me, thanks for the test case (btw maybe it's worth
> > mentioning in the commit message that the test fails without doing
> > gt.resume?)
>
> That would mean doing actual work to dig out the original failing bug
> reports!
Added,
References: https://bugs.freedesktop.org/show_bug.cgi?id=96526
References: 5ab57c702069 ("drm/i915: Flush logical context image out to
memory upon suspend")
and pushed. Pleasure to be of service,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/selftests: Add a simple exerciser for suspend/hibernate
Quoting Bartminski, Jakub (2018-08-31 10:01:57) > Looks good to me, thanks for the test case (btw maybe it's worth > mentioning in the commit message that the test fails without doing > gt.resume?) That would mean doing actual work to dig out the original failing bug reports! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/selftests: Add a simple exerciser for suspend/hibernate
Looks good to me, thanks for the test case (btw maybe it's worth
mentioning in the commit message that the test fails without doing
gt.resume?)
Reviewed-by: Jakub Bartmiński
On Thu, 2018-08-30 at 14:48 +0100, Chris Wilson wrote:
> Although we cannot do a full system-level test of suspend/hibernate
> from
> deep with the kernel selftests, we can exercise the GEM subsystem in
> isolation and simulate the external effects (such as losing stolen
> contents and trashing the register state).
>
> v2: Don't forget to hold rpm
> v3: Suspend the GTT mappings, and more rpm!
>
> Signed-off-by: Chris Wilson
> Cc: Jakub Bartmiński
> Cc: Matthew Auld
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem.c | 1 +
> drivers/gpu/drm/i915/selftests/i915_gem.c | 221
> ++
> .../drm/i915/selftests/i915_live_selftests.h | 1 +
> 3 files changed, 223 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem.c
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 0453eb42a1a3..7b7bbfe59697 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -6207,4 +6207,5 @@ int i915_gem_object_attach_phys(struct
> drm_i915_gem_object *obj, int align)
> #include "selftests/huge_pages.c"
> #include "selftests/i915_gem_object.c"
> #include "selftests/i915_gem_coherency.c"
> +#include "selftests/i915_gem.c"
> #endif
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> new file mode 100644
> index ..e9cfc1fb0c07
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -0,0 +1,221 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright © 2018 Intel Corporation
> + */
> +
> +#include
> +
> +#include "../i915_selftest.h"
> +
> +#include "mock_context.h"
> +#include "igt_flush_test.h"
> +
> +static int switch_to_context(struct drm_i915_private *i915,
> + struct i915_gem_context *ctx)
> +{
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + int err = 0;
> +
> + intel_runtime_pm_get(i915);
> +
> + for_each_engine(engine, i915, id) {
> + struct i915_request *rq;
> +
> + rq = i915_request_alloc(engine, ctx);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + break;
> + }
> +
> + i915_request_add(rq);
> + }
> +
> + intel_runtime_pm_put(i915);
> +
> + return err;
> +}
> +
> +static int pm_prepare(struct drm_i915_private *i915)
> +{
> + int err = 0;
> +
> + if (i915_gem_suspend(i915)) {
> + pr_err("i915_gem_suspend failed\n");
> + err = -EINVAL;
> + }
> +
> + return err;
> +}
> +
> +static void trash_stolen(struct drm_i915_private *i915)
> +{
> + struct i915_ggtt *ggtt = >ggtt;
> + const u64 slot = ggtt->error_capture.start;
> + const resource_size_t size = resource_size(>dsm);
> + unsigned long page;
> + u32 prng = 0x12345678;
> +
> + for (page = 0; page < size; page += PAGE_SIZE) {
> + const dma_addr_t dma = i915->dsm.start + page;
> + u32 __iomem *s;
> + int x;
> +
> + ggtt->vm.insert_page(>vm, dma, slot,
> I915_CACHE_NONE, 0);
> +
> + s = io_mapping_map_atomic_wc(>iomap, slot);
> + for (x = 0; x < PAGE_SIZE / sizeof(u32); x++) {
> + prng = next_pseudo_random32(prng);
> + iowrite32(prng, [x]);
> + }
> + io_mapping_unmap_atomic(s);
> + }
> +
> + ggtt->vm.clear_range(>vm, slot, PAGE_SIZE);
> +}
> +
> +static void simulate_hibernate(struct drm_i915_private *i915)
> +{
> + intel_runtime_pm_get(i915);
> +
> + /*
> + * As a final sting in the tail, invalidate stolen. Under a
> real S4,
> + * stolen is lost and needs to be refilled on resume.
> However, under
> + * CI we merely do S4-device testing (as full S4 is too
> unreliable
> + * for automated testing across a cluster), so to simulate
> the effect
> + * of stolen being trashed across S4, we trash it ourselves.
> + */
> + trash_stolen(i915);
> +
> + intel_runtime_pm_put(i915);
> +}
> +
> +static void pm_resume(struct drm_i915_private *i915)
> +{
> + /*
> + * Both suspend and hibernate follow the same wakeup path
> and assume
> + * that runtime-pm just works.
> + */
> + intel_runtime_pm_get(i915);
> +
> + intel_engines_sanitize(i915);
> + i915_gem_sanitize(i915);
> + i915_gem_resume(i915);
> +
> + intel_runtime_pm_put(i915);
> +}
> +
> +static void pm_suspend(struct drm_i915_private *i915)
> +{
> + intel_runtime_pm_get(i915);
> +
> + i915_gem_suspend_gtt_mappings(i915);
> + i915_gem_suspend_late(i915);
> +
> + intel_runtime_pm_put(i915);
> +}
> +
> +static int igt_gem_suspend(void *arg)
> +{
> +
Re: [Intel-gfx] [PATCH libdrm v2 4/5] intel: make gen9 use generic gen macro
Quoting Lucas De Marchi (2018-08-29 01:35:31)
> The 2 PCI IDs that are used for the command line overrid mechanism
> were left defined. The rest can be gone and then we just use the kernel
> defines.
>
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_chipset.c | 5 ++
> intel/intel_chipset.h | 187 +-
> 2 files changed, 6 insertions(+), 186 deletions(-)
>
> diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
> index 0c2ba884..c984d8ac 100644
> --- a/intel/intel_chipset.c
> +++ b/intel/intel_chipset.c
> @@ -36,6 +36,11 @@ static const struct pci_device {
> } pciids[] = {
> INTEL_ICL_11_IDS(11),
> INTEL_CNL_IDS(10),
> + INTEL_CFL_IDS(9),
> + INTEL_GLK_IDS(9),
> + INTEL_KBL_IDS(9),
> + INTEL_BXT_IDS(9),
> + INTEL_SKL_IDS(9),
The gradual conversion lgtm. But why stop here? :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm v2 4/5] intel: make gen9 use generic gen macro
Quoting Lucas De Marchi (2018-08-29 17:01:11) > On Wed, Aug 29, 2018 at 11:32:35AM +0100, Chris Wilson wrote: > > Quoting Lucas De Marchi (2018-08-29 01:35:31) > > > The 2 PCI IDs that are used for the command line overrid mechanism > > > were left defined. > > > > What makes them so special? Why not just match on the override devid? > > because it's a name -> id mapping? It maps a short string like "skl" to > a single specific PCI ID... how useful is that and if we should retain > its behavior, I have dunno. But > i915_pciids.h doesn't have defines for individual PCI IDs, but groups of > them. My bad, I've always used pci-id overrides as a pci-id! > I would either have to create an accessor/iter for gen x in > intel_chipset.c or do some macros to extract the first id from the > i915_pciids.h, just to get an ID that is set in stone and change the > current id used :-/ Having the i915_pciids.h contain the codename (and /rough/ marketing name) was pencilled in to my plans now that it no longer appears to be a freak out. Once we have configurable macros, the extra parameters just disappear when unwanted. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm v2 1/5] intel: add generic functions to check PCI ID
Quoting Lucas De Marchi (2018-08-29 01:35:28)
> +static const struct pci_device {
> + uint16_t device;
> + uint16_t gen;
> +} pciids[] = {
Add a comment here as well for the ordering requirement.
/* Keep ids sorted by gen; latest gen first */
We're unlikely to notice a comment in the function later trying to
impose its restriction.
> +};
> +
> +bool intel_is_genx(unsigned int devid, int gen)
> +{
> + const struct pci_device *p,
> + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> +
> + for (p = pciids; p < pend; p++) {
> + /* PCI IDs are sorted */
> + if (p->gen < gen)
> + break;
If we have lots of gen with lots of subids, a binary search for gen
would be sensible. However, do we need this function? Do we not just
convert everyone over to a lookup of pci-id on entry?
> +
> + if (p->device != devid)
> + continue;
> +
> + if (gen == p->gen)
> + return true;
> +
> + break;
> + }
> +
> + return false;
> +}
> +
> +bool intel_get_genx(unsigned int devid, int *gen)
> +{
> + const struct pci_device *p,
> + *pend = pciids + sizeof(pciids) / sizeof(pciids[0]);
> +
> + for (p = pciids; p < pend; p++) {
> + if (p->device != devid)
> + continue;
> +
> + if (gen)
> + *gen = p->gen;
> +
> + return true;
> + }
> +
> + return false;
> +}
Idle thought
#ifdef SELFTEST
int main(void)
{
/* check pci-ids are ordered by gen */
}
#endif
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 4a34b7be..0e14c58f 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -568,6 +568,13 @@
>
> #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
>
> +/* New platforms use kernel pci ids */
> +#include
> +
> +bool intel_is_genx(unsigned int devid, int gen);
> +bool intel_get_genx(unsigned int devid, int *gen);
> +
> +/* all platforms */
Quite clearly not all platforms :-p
> #define IS_9XX(dev)(IS_GEN3(dev) || \
> IS_GEN4(dev) || \
> IS_GEN5(dev) || \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915/selftests: Add a simple exerciser for suspend/hibernate
Quoting Chris Wilson (2018-08-30 14:48:06)
> Although we cannot do a full system-level test of suspend/hibernate from
> deep with the kernel selftests, we can exercise the GEM subsystem in
> isolation and simulate the external effects (such as losing stolen
> contents and trashing the register state).
>
> v2: Don't forget to hold rpm
> v3: Suspend the GTT mappings, and more rpm!
>
> Signed-off-by: Chris Wilson
> Cc: Jakub Bartmiński
> Cc: Matthew Auld
> Cc: Joonas Lahtinen
The dust has finally settled; care for a perusal?
-Chris
> ---
> drivers/gpu/drm/i915/i915_gem.c | 1 +
> drivers/gpu/drm/i915/selftests/i915_gem.c | 221 ++
> .../drm/i915/selftests/i915_live_selftests.h | 1 +
> 3 files changed, 223 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem.c
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0453eb42a1a3..7b7bbfe59697 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -6207,4 +6207,5 @@ int i915_gem_object_attach_phys(struct
> drm_i915_gem_object *obj, int align)
> #include "selftests/huge_pages.c"
> #include "selftests/i915_gem_object.c"
> #include "selftests/i915_gem_coherency.c"
> +#include "selftests/i915_gem.c"
> #endif
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
> b/drivers/gpu/drm/i915/selftests/i915_gem.c
> new file mode 100644
> index ..e9cfc1fb0c07
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
> @@ -0,0 +1,221 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright © 2018 Intel Corporation
> + */
> +
> +#include
> +
> +#include "../i915_selftest.h"
> +
> +#include "mock_context.h"
> +#include "igt_flush_test.h"
> +
> +static int switch_to_context(struct drm_i915_private *i915,
> +struct i915_gem_context *ctx)
> +{
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + int err = 0;
> +
> + intel_runtime_pm_get(i915);
> +
> + for_each_engine(engine, i915, id) {
> + struct i915_request *rq;
> +
> + rq = i915_request_alloc(engine, ctx);
> + if (IS_ERR(rq)) {
> + err = PTR_ERR(rq);
> + break;
> + }
> +
> + i915_request_add(rq);
> + }
> +
> + intel_runtime_pm_put(i915);
> +
> + return err;
> +}
> +
> +static int pm_prepare(struct drm_i915_private *i915)
> +{
> + int err = 0;
> +
> + if (i915_gem_suspend(i915)) {
> + pr_err("i915_gem_suspend failed\n");
> + err = -EINVAL;
> + }
> +
> + return err;
> +}
> +
> +static void trash_stolen(struct drm_i915_private *i915)
> +{
> + struct i915_ggtt *ggtt = >ggtt;
> + const u64 slot = ggtt->error_capture.start;
> + const resource_size_t size = resource_size(>dsm);
> + unsigned long page;
> + u32 prng = 0x12345678;
> +
> + for (page = 0; page < size; page += PAGE_SIZE) {
> + const dma_addr_t dma = i915->dsm.start + page;
> + u32 __iomem *s;
> + int x;
> +
> + ggtt->vm.insert_page(>vm, dma, slot, I915_CACHE_NONE,
> 0);
> +
> + s = io_mapping_map_atomic_wc(>iomap, slot);
> + for (x = 0; x < PAGE_SIZE / sizeof(u32); x++) {
> + prng = next_pseudo_random32(prng);
> + iowrite32(prng, [x]);
> + }
> + io_mapping_unmap_atomic(s);
> + }
> +
> + ggtt->vm.clear_range(>vm, slot, PAGE_SIZE);
> +}
> +
> +static void simulate_hibernate(struct drm_i915_private *i915)
> +{
> + intel_runtime_pm_get(i915);
> +
> + /*
> +* As a final sting in the tail, invalidate stolen. Under a real S4,
> +* stolen is lost and needs to be refilled on resume. However, under
> +* CI we merely do S4-device testing (as full S4 is too unreliable
> +* for automated testing across a cluster), so to simulate the effect
> +* of stolen being trashed across S4, we trash it ourselves.
> +*/
> + trash_stolen(i915);
> +
> + intel_runtime_pm_put(i915);
> +}
> +
> +static void pm_resume(struct drm_i915_private *i915)
> +{
> + /*
> +* Both suspend and hibernate follow the same wakeup path and assume
> +* that runtime-pm just works.
> +*/
> + intel_runtime_pm_get(i915);
> +
> + intel_engines_sanitize(i915);
> + i915_gem_sanitize(i915);
> + i915_gem_resume(i915);
> +
> + intel_runtime_pm_put(i915);
> +}
> +
> +static void pm_suspend(struct drm_i915_private *i915)
> +{
> + intel_runtime_pm_get(i915);
> +
> + i915_gem_suspend_gtt_mappings(i915);
> + i915_gem_suspend_late(i915);
> +
> + intel_runtime_pm_put(i915);
> +}
> +
> +static int igt_gem_suspend(void *arg)
> +{
> + struct
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL. (rev6)
== Series Details == Series: drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL. (rev6) URL : https://patchwork.freedesktop.org/series/48803/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4745_full -> Patchwork_10057_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10057_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10057_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_10057_full: === IGT changes === Warnings igt@kms_concurrent@pipe-b: shard-snb: SKIP -> PASS +1 igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-xtiled: shard-snb: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_10057_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) Possible fixes igt@drv_suspend@shrink: shard-hsw: INCOMPLETE (fdo#106886, fdo#103540) -> PASS shard-apl: INCOMPLETE (fdo#106886, fdo#103927) -> PASS shard-glk: FAIL (fdo#106886) -> PASS igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105363) -> PASS +1 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4745 -> Patchwork_10057 CI_DRM_4745: 4ddf5e7833fae7268e674ddea403a24b36c8337d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4612: e39e09910fc8e369e24f6a0cabaeb9356dbfae08 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10057: 225ce5d7d0c64e3c963e105a4e8d05d4533539fe @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10057/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Keep physical cursors pinned while in use
Quoting Ville Syrjälä (2018-08-22 13:35:52)
> On Fri, Aug 17, 2018 at 09:24:05AM +0100, Chris Wilson wrote:
> > The optimisation inherent in commit 6a2c4232ece1 ("drm/i915: Make the
> > physical object coherent with GTT") relies on that once we allocated a
> > cursor we would have coherent, zero overhead access to the scanout plane
> > holding the cursor. That is we could then do the very frequent cursor
> > updates X enjoys with no indirection or kernel involvement. However,
> > that all hinges on the GGTT mmap of the cursor being pinned and not
> > require refaulting on each access -- handling such a page fault likely
> > requires the busy GGTT to be rearranged causing a stall. A very simple
> > fix is then to handle the physical cursor exactly like other cursors and
> > keep its vma pinned while active.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107600
>
> I guess this wasn't the thing we wanted. But seems quite harmless to
> me anyway, so
It ties neatly in with the ggtt map being used for updates, so I think
it's harmless enough. If I could just get a contiguous page out of
shmemfs, I could follow up with the removal of phys_object. :|
>
> Reviewed-by: Ville Syrjälä
>
> in case you still want to land it.
But without the bugzilla since that bug is occurring without cursor
updates, so is even more bizarre.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 2/2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.
On Thu, 2018-08-30 at 11:15 -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-08-30 at 13:57 +0100, Lisovskiy, Stanislav wrote:
> > On Wed, 2018-08-29 at 12:16 -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Wed, 2018-08-29 at 21:10 +0300, Ville Syrjälä wrote:
> > > > On Wed, Aug 29, 2018 at 02:28:47PM +0300, Stanislav Lisovskiy
> > > > wrote:
> > > > > PLANE_CTL_FORMAT_AYUV is already supported, according to
> > > > > hardware
> > > > > specification.
> > > > >
> > > > > v2: Edited commit message, removed redundant whitespaces.
> > > > >
> > > > > v3: Fixed fallthrough logic for the format switch cases.
> > > > >
> > > > > v4: Yet again fixed fallthrough logic, to reuse code from
> > > > > other
> > > > > case
> > > > > labels.
> > > > >
> > > > > v5: Started to use XYUV instead of AYUV, as we don't use
> > > > > alpha.
>
> Curious what the reason is. Is it because the hardware does not
> support
> alpha with this format?
As I understood yes, this is a hardware limitation.
>
> > > > >
> > > > > v6: Removed unneeded initializer for new XYUV format.
> > > > >
> > > > > v7: Added scaling support for DRM_FORMAT_XYUV
> > >
> > > I don't see yuv formats in skl_format_to_fourcc(), any idea why?
> >
> > Good point. I guess would be nice idea to add at least XYUV there
> > now.
> > I can add rest of the formats with a separate patch afterwards.
>
> Wonder if the expectation is BIOS not use yuv formats. Ville?
I talked to Ville yesterday, I think that was basically what he said.
>
> >
> > >
> > > Also, shouldn't plane_color_ctl_alpha() be updated?
> >
> > I guess not, as we don't support alpha in that case.
>
> Right, the default case should take care of setting
> PLANE_CTL_ALPHA_DISABLE. I misread it.
>
> >
> > >
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy > > > > .c
> > > > > om
> > > > > >
> > > > >
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_display.c | 8
> > > > > drivers/gpu/drm/i915/intel_sprite.c | 1 +
> > > > > 2 files changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index 30fdfd1a3037..3c96fa3a2b61 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[]
> > > > > =
> > > > > {
> > > > > DRM_FORMAT_YVYU,
> > > > > DRM_FORMAT_UYVY,
> > > > > DRM_FORMAT_VYUY,
> > > > > + DRM_FORMAT_XYUV,
> > > > > };
> > > > >
> > > > > static const uint32_t skl_pri_planar_formats[] = {
> > > > > @@ -102,6 +103,7 @@ static const uint32_t
> > > > > skl_pri_planar_formats[]
> > > > > = {
> > > > > DRM_FORMAT_UYVY,
> > > > > DRM_FORMAT_VYUY,
> > > > > DRM_FORMAT_NV12,
> > > > > + DRM_FORMAT_XYUV,
> > > >
> > > > I would keep the NV12 at the end so that the arrays are easier
> > > > to
> > > > compare visually.
> > > >
> > > > > };
> > > > >
> > > > > static const uint64_t skl_format_modifiers_noccs[] = {
> > > > > @@ -3501,6 +3503,8 @@ static u32
> > > > > skl_plane_ctl_format(uint32_t
> > > > > pixel_format)
> > > > > return PLANE_CTL_FORMAT_XRGB_2101010;
> > > > > case DRM_FORMAT_XBGR2101010:
> > > > > return PLANE_CTL_ORDER_RGBX |
> > > > > PLANE_CTL_FORMAT_XRGB_2101010;
> > > > > + case DRM_FORMAT_XYUV:
> > > > > + return PLANE_CTL_FORMAT_AYUV;
> > > >
> > > > We should probably rename that define to XYUV as well since it
> > > > doesn't
> > > > support per-pixel alpha.
> > > >
> > > > Since you've only implemented this for skl+ you chould mention
> > > > that
> > > > in the commit msg. IVB+ support should be equally trivial to
> > > > implement (wink wink).
> > > >
> > > > > case DRM_FORMAT_YUYV:
> > > > > return PLANE_CTL_FORMAT_YUV422 |
> > > > > PLANE_CTL_YUV422_YUYV;
> > > > > case DRM_FORMAT_YVYU:
> > > > > @@ -4959,6 +4963,7 @@ static int
> > > > > skl_update_scaler_plane(struct
> > > > > intel_crtc_state *crtc_state,
> > > > > case DRM_FORMAT_UYVY:
> > > > > case DRM_FORMAT_VYUY:
> > > > > case DRM_FORMAT_NV12:
> > > > > + case DRM_FORMAT_XYUV:
> > > > > break;
> > > > > default:
> > > > > DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d
> > > > > unsupported
> > > > > scaling format 0x%x\n",
> > > > > @@ -13399,6 +13404,7 @@ static bool
> > > > > skl_plane_format_mod_supported(struct drm_plane *_plane,
> > > > > }
> > > > >
> > > > > switch (format) {
> > > > > +
> > > >
> > > > Bogus whitespace.
> > > >
> > > > > case DRM_FORMAT_XRGB:
> > > > > case DRM_FORMAT_XBGR:
> > > > > case DRM_FORMAT_ARGB:
> > > > > @@ -13414,6 +13420,7 @@ static bool
> > > > > skl_plane_format_mod_supported(struct drm_plane *_plane,
> > > > > case DRM_FORMAT_UYVY:
> > > > > case DRM_FORMAT_VYUY:
> > > > > case
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL. (rev6)
== Series Details ==
Series: drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL. (rev6)
URL : https://patchwork.freedesktop.org/series/48803/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4745 -> Patchwork_10057 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/48803/revisions/6/mbox/
== Known issues ==
Here are the changes found in Patchwork_10057 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
Possible fixes
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
{fi-byt-clapper}: FAIL (fdo#107362, fdo#103191) -> PASS +1
{igt@pm_rpm@module-reload}:
fi-cnl-psr: WARN (fdo#107708, fdo#107602) -> PASS
{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#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107602 https://bugs.freedesktop.org/show_bug.cgi?id=107602
fdo#107708 https://bugs.freedesktop.org/show_bug.cgi?id=107708
== Participating hosts (54 -> 47) ==
Missing(7): fi-hsw-4770r fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005
== Build changes ==
* Linux: CI_DRM_4745 -> Patchwork_10057
CI_DRM_4745: 4ddf5e7833fae7268e674ddea403a24b36c8337d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4612: e39e09910fc8e369e24f6a0cabaeb9356dbfae08 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10057: 225ce5d7d0c64e3c963e105a4e8d05d4533539fe @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
225ce5d7d0c6 drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10057/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] [intel-gfx] drm/i915/intel_csr.c Fix DMC FW Loading issue on ICL.
This patch resolves the DMC FW loading issue.
Earlier DMC FW package have only one DMC FW for one stepping. But as such
there is no such restriction from Package side.
For ICL icl_dmc_ver1_07.bin binary package has DMC FW for 2 steppings.
So while reading the dmc_offset from package header, for 1st stepping
offset used to come 0x0 and was working fine till now.
But for second stepping and other steppings, offset is non zero number
and is in dwords. So we need to convert into bytes to fetch correct DMC
FW from correct place.
v2 : Added check for DMC FW max size for various gen. (Imre Deak)
v3 : Corrected naming convention for various gen. (Imre Deak)
v4 : Initialized max_fw_size to 0
v5 : Corrected DMC FW MAX_SIZE for various gen. (Imre Deak)
v6 : Fixed the typo issues.
Reviewed-by: Imre Deak
Signed-off-by: Jyoti Yadav
---
drivers/gpu/drm/i915/intel_csr.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 1ec4f09..14cf4c3 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -55,7 +55,9 @@
#define BXT_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
-#define CSR_MAX_FW_SIZE0x2FFF
+#define BXT_CSR_MAX_FW_SIZE0x3000
+#define GLK_CSR_MAX_FW_SIZE0x4000
+#define ICL_CSR_MAX_FW_SIZE0x6000
#define CSR_DEFAULT_FW_OFFSET 0x
struct intel_css_header {
@@ -279,6 +281,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
struct intel_csr *csr = _priv->csr;
const struct stepping_info *si = intel_get_stepping_info(dev_priv);
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
+ uint32_t max_fw_size = 0;
uint32_t i;
uint32_t *dmc_payload;
uint32_t required_version;
@@ -359,6 +362,8 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
si->stepping);
return NULL;
}
+ /* Convert dmc_offset into number of bytes. By default it is in dwords*/
+ dmc_offset *= 4;
readcount += dmc_offset;
/* Extract dmc_header information. */
@@ -391,8 +396,16 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
/* fw_size is in dwords, so multiplied by 4 to convert into bytes. */
nbytes = dmc_header->fw_size * 4;
- if (nbytes > CSR_MAX_FW_SIZE) {
- DRM_ERROR("DMC firmware too big (%u bytes)\n", nbytes);
+ if (INTEL_GEN(dev_priv) >= 11)
+ max_fw_size = ICL_CSR_MAX_FW_SIZE;
+ else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ max_fw_size = GLK_CSR_MAX_FW_SIZE;
+ else if (IS_GEN9(dev_priv))
+ max_fw_size = BXT_CSR_MAX_FW_SIZE;
+ else
+ MISSING_CASE(INTEL_REVID(dev_priv));
+ if (nbytes > max_fw_size) {
+ DRM_ERROR("DMC FW too big (%u bytes)\n", nbytes);
return NULL;
}
csr->dmc_fw_size = dmc_header->fw_size;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
