Re: [Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

[Alex Deucher]

On Wed, Nov 1, 2017 at 10:20 AM, Jani Nikula  wrote:
> We were recently bitten by drm_edid_to_eld() clearing the connector
> type, and us failing to set it back for DP. Here's a few ELD related
> patches to try to unify ELD handling and make it a bit simpler for
> drivers to get it right.
>
> Apologies for the massive Cc list; it's the maintainers of all drivers
> that call drm_edid_to_eld().
>
> I'm open to splitting up patch 6 to driver specific patches as needed,
> but I'd think it would be just fine to merge via drm-misc as-is too.

Nice!  Series is:
Reviewed-by: Alex Deucher 


>
> BR,
> Jani.
>
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Russell King 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> Cc: Ben Skeggs 
> Cc: Mark Yao 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Thierry Reding 
> Cc: Eric Anholt 
>
>
> Jani Nikula (7):
>   drm/edid: use macros for ELD offsets and values
>   drm/edid: set ELD connector type in drm_edid_to_eld()
>   drm/i915: remove redundant ELD connector type update
>   drm/edid: abstract connector ELD clearing
>   drm/edid: build ELD in drm_add_edid_modes()
>   drm/drivers: drop redundant drm_edid_to_eld() calls
>   drm/edid: make drm_edid_to_eld() static
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  1 -
>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  2 -
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  2 -
>  drivers/gpu/drm/drm_edid.c | 70 
> +++---
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  1 -
>  drivers/gpu/drm/i915/intel_dp.c|  1 -
>  drivers/gpu/drm/i915/intel_modes.c | 18 ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  1 -
>  drivers/gpu/drm/nouveau/nv50_display.c |  5 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c |  1 -
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  1 -
>  drivers/gpu/drm/rockchip/cdn-dp-core.c |  4 +-
>  drivers/gpu/drm/sti/sti_hdmi.c |  1 -
>  drivers/gpu/drm/tegra/output.c |  1 -
>  drivers/gpu/drm/vc4/vc4_hdmi.c |  1 -
>  include/drm/drm_edid.h |  1 -
>  include/drm/drm_modeset_helper_vtables.h   |  3 --
>  17 files changed, 44 insertions(+), 70 deletions(-)
>
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dmc: DMC 1.04 for Kabylake

[Anusha Srivatsa]

There is a new version of DMC available for KBL.

The release notes mentions:
1. Fix for the issue where DC_STATE was getting enabled even
when disabled by driver causing data corruption.

Adding the pull request here as an experiment-
The following changes since commit bf04291309d3169c0ad3b8db52564235bbd08e30:

  WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100)

are available in the git repository at:

  https://github.com/anushasr/linux-firmware.git KBL_DMC

for you to fetch changes up to 2f2b42764455856c2ba63d2154b3b2fbb7424236:

  linux-firmware: DMC firmware for kabylake v1.04 (2017-11-01 19:22:21 -0700)


Anusha Srivatsa (1):
  linux-firmware: DMC firmware for kabylake v1.04

 WHENCE   |   4 
 i915/kbl_dmc_ver1_04.bin | Bin 0 -> 8840 bytes
 2 files changed, 4 insertions(+)
 create mode 100644 i915/kbl_dmc_ver1_04.bin

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_csr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 3e1f86d..5842777 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -40,9 +40,9 @@
 #define I915_CSR_CNL "i915/cnl_dmc_ver1_06.bin"
 #define CNL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 6)
 
-#define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
+#define I915_CSR_KBL "i915/kbl_dmc_ver1_04.bin"
 MODULE_FIRMWARE(I915_CSR_KBL);
-#define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 1)
+#define KBL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 4)
 
 #define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
 MODULE_FIRMWARE(I915_CSR_SKL);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Clear terminated attribute bit on GuC preemption context

[Michel Thierry]

On 01/11/17 15:16, jeff.mc...@intel.com wrote:

From: Jeff McGee 

If GuC firmware performs an engine reset while that engine had a
preemption pending, it will set the terminated attribute bit on our
preemption stage descriptor. GuC firmware retains all pending work
items for a high-priority GuC client, unlike the normal-priority GuC
client where work items are dropped. It wants to make sure the preempt-
to-idle work doesn't run when scheduling resumes, and uses this bit to
inform its scheduler and presumably us as well. Our job is to clear it
for the next preemption after reset, otherwise that and future
preemptions will never complete. We'll just clear it every time.

Signed-off-by: Jeff McGee 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 3049a0781b88..d14c1342f09d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -590,6 +590,7 @@ static void inject_preempt_context(struct work_struct *work)
 struct intel_guc *guc = container_of(preempt_work, typeof(*guc),
  preempt_work[engine->id]);
 struct i915_guc_client *client = guc->preempt_client;
+   struct guc_stage_desc *stage_desc = __get_stage_desc(client);
 struct intel_ring *ring = client->owner->engine[engine->id].ring;
 u32 ctx_desc = lower_32_bits(intel_lr_context_descriptor(client->owner,
  engine));
@@ -623,6 +624,20 @@ static void inject_preempt_context(struct work_struct 
*work)
ring->tail / sizeof(u64), 0);
 spin_unlock_irq(>wq_lock);

+   /*
+* If GuC firmware performs an engine reset while that engine had
+* a preemption pending, it will set the terminated attribute bit
+* on our preemption stage descriptor. GuC firmware retains all
+* pending work items for a high-priority GuC client, unlike the
+* normal-priority GuC client where work items are dropped. It
+* wants to make sure the preempt-to-idle work doesn't run when
+* scheduling resumes, and uses this bit to inform its scheduler
+* and presumably us as well. Our job is to clear it for the next
+* preemption after reset, otherwise that and future preemptions
+* will never complete. We'll just clear it every time.
+*/
+   stage_desc->attribute &= ~GUC_STAGE_DESC_ATTR_TERMINATED;
+


I looked around and yes, the firmware will set the terminated bit in the 
stage_desc of the preempt client if it had a pending preemption request. 
No harm in clearing it unconditionally.



 data[0] = INTEL_GUC_ACTION_REQUEST_PREEMPTION;
 data[1] = client->stage_id;
 data[2] = INTEL_GUC_PREEMPT_OPTION_DROP_WORK_Q |
--
2.14.2


Since Michał is not around,

Reviewed-by: Michel Thierry 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt v2] igt/gem_ctx_isolation: Check isolation of registers between contexts

[Chris Wilson]

A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.

v2: extend back to Sandybridge, ignore non-priv registers that are not
context-saved (remind me what this test is all about!!!)

Signed-off-by: Chris Wilson 
---
 tests/Makefile.sources|   1 +
 tests/gem_ctx_isolation.c | 658 ++
 2 files changed, 659 insertions(+)
 create mode 100644 tests/gem_ctx_isolation.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2313c12b..9a25a8b5 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -56,6 +56,7 @@ TESTS_progs = \
gem_ctx_basic \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
gem_ctx_thrash \
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
new file mode 100644
index ..9c5ec181
--- /dev/null
+++ b/tests/gem_ctx_isolation.c
@@ -0,0 +1,658 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "igt_dummyload.h"
+
+#define MAX_REG 0x4
+#define NUM_REGS (MAX_REG / sizeof(uint32_t))
+
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
+
+#define DIRTY1 0x1
+#define DIRTY2 0x2
+#define UNSAFE 0x4
+
+enum {
+   RCS_MASK = 0x1,
+   BCS_MASK = 0x2,
+   VCS_MASK = 0x4,
+   VECS_MASK = 0x8,
+};
+
+#define ALL ~0u
+#define GEN_RANGE(x, y) ((ALL >> (32 - (y - x + 1))) << x)
+#define GEN6 (ALL << 6)
+#define GEN7 (ALL << 7)
+#define GEN8 (ALL << 8)
+
+#define NOCTX 0
+
+#define LAST_KNOWN_GEN 10
+
+static const struct named_register {
+   const char *name;
+   unsigned int gen_mask;
+   unsigned int engine_mask;
+   uint32_t offset;
+   uint32_t count;
+} safe_registers[] = {
+   { "NOPID", NOCTX, RCS_MASK, 0x2094 },
+   { "MI_PREDICATE_RESULT_2", NOCTX, RCS_MASK, 0x23bc },
+   { "INSTPM", GEN8, RCS_MASK, 0x20c0 },
+   { "IA_VERTICES_COUNT", GEN6, RCS_MASK, 0x2310, 2 },
+   { "IA_PRIMITIVES_COUNT", GEN6, RCS_MASK, 0x2318, 2 },
+   { "VS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2320, 2 },
+   { "HS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2300, 2 },
+   { "DS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2308, 2 },
+   { "GS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2328, 2 },
+   { "GS_PRIMITIVES_COUNT", GEN6, RCS_MASK, 0x2330, 2 },
+   { "CL_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2338, 2 },
+   { "CL_PRIMITIVES_COUNT", GEN6, RCS_MASK, 0x2340, 2 },
+   { "PS_INVOCATION_COUNT_0", GEN6, RCS_MASK, 0x22c8, 2 },
+   { "PS_DEPTH_COUNT_0", GEN6, RCS_MASK, 0x22d8, 2 },
+   { "GPUGPU_DISPATCHDIMX", GEN8, RCS_MASK, 0x2500 },
+   { "GPUGPU_DISPATCHDIMY", GEN8, RCS_MASK, 0x2504 },
+   { "GPUGPU_DISPATCHDIMZ", GEN8, RCS_MASK, 0x2508 },
+   { "MI_PREDICATE_SRC0", GEN8, RCS_MASK, 0x2400, 2 },
+   { "MI_PREDICATE_SRC1", GEN8, RCS_MASK, 0x2408, 2 },
+   { "MI_PREDICATE_DATA", GEN8, RCS_MASK, 0x2410, 2 },
+   { "MI_PRED_RESULT", GEN8, RCS_MASK, 0x2418 },
+   { "3DPRIM_END_OFFSET", GEN6, RCS_MASK, 0x2420 },
+   { "3DPRIM_START_VERTEX", GEN6, RCS_MASK, 0x2430 },
+   { "3DPRIM_VERTEX_COUNT", GEN6, RCS_MASK, 0x2434 },
+   { "3DPRIM_INSTANCE_COUNT", GEN6, RCS_MASK, 0x2438 },
+   { "3DPRIM_START_INSTANCE", GEN6, RCS_MASK, 0x243c },
+   { "3DPRIM_BASE_VERTEX", GEN6, RCS_MASK, 0x2440 },
+   { "GPGPU_THREADS_DISPATCHED", GEN8, RCS_MASK, 0x2290, 2 },
+   { "PS_INVOCATION_COUNT_1", GEN8, RCS_MASK, 0x22f0, 2 },
+   { "PS_DEPTH_COUNT_1", GEN8, RCS_MASK, 0x22f8, 2 },
+   { "BB_OFFSET", GEN8, RCS_MASK, 0x2158 },
+   { "MI_PREDICATE_RESULT_1", GEN8, RCS_MASK, 0x241c },
+   { "CS_GPR", GEN8, RCS_MASK, 0x2600, 32 },
+   

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear

[Chris Wilson]

Quoting Arun Siluvery (2016-06-03 12:40:00)
> Kernel only need to add a register to HW whitelist, required for a
> preemption related issue.
> 
> Reference: HSD#2131039
> Signed-off-by: Arun Siluvery 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e307725..1f6040a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6072,6 +6072,7 @@ enum skl_disp_power_wells {
>  #define  GEN9_TSG_BARRIER_ACK_DISABLE  (1<<8)
>  
>  #define GEN9_CS_DEBUG_MODE1_MMIO(0x20ec)
> +#define GEN9_CTX_PREEMPT_REG   _MMIO(0x2248)
>  #define GEN8_CS_CHICKEN1   _MMIO(0x2580)
>  
>  /* GEN7 chicken */
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 8d35a39..1f9d3a4 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -987,6 +987,11 @@ static int gen9_init_workarounds(struct intel_engine_cs 
> *engine)
> I915_WRITE(GEN8_L3SQCREG4, (I915_READ(GEN8_L3SQCREG4) |
> GEN8_LQSC_FLUSH_COHERENT_LINES));
>  
> +   /* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt */
> +   ret= wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
> +   if (ret)
> +   return ret;

What is for exactly? This register is not context saved, so...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc: Clear terminated attribute bit on GuC preemption context

[jeff . mcgee]

From: Jeff McGee 

If GuC firmware performs an engine reset while that engine had a
preemption pending, it will set the terminated attribute bit on our
preemption stage descriptor. GuC firmware retains all pending work
items for a high-priority GuC client, unlike the normal-priority GuC
client where work items are dropped. It wants to make sure the preempt-
to-idle work doesn't run when scheduling resumes, and uses this bit to
inform its scheduler and presumably us as well. Our job is to clear it
for the next preemption after reset, otherwise that and future
preemptions will never complete. We'll just clear it every time.

Signed-off-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 3049a0781b88..d14c1342f09d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -590,6 +590,7 @@ static void inject_preempt_context(struct work_struct *work)
struct intel_guc *guc = container_of(preempt_work, typeof(*guc),
 preempt_work[engine->id]);
struct i915_guc_client *client = guc->preempt_client;
+   struct guc_stage_desc *stage_desc = __get_stage_desc(client);
struct intel_ring *ring = client->owner->engine[engine->id].ring;
u32 ctx_desc = lower_32_bits(intel_lr_context_descriptor(client->owner,
 engine));
@@ -623,6 +624,20 @@ static void inject_preempt_context(struct work_struct 
*work)
   ring->tail / sizeof(u64), 0);
spin_unlock_irq(>wq_lock);
 
+   /*
+* If GuC firmware performs an engine reset while that engine had
+* a preemption pending, it will set the terminated attribute bit
+* on our preemption stage descriptor. GuC firmware retains all
+* pending work items for a high-priority GuC client, unlike the
+* normal-priority GuC client where work items are dropped. It
+* wants to make sure the preempt-to-idle work doesn't run when
+* scheduling resumes, and uses this bit to inform its scheduler
+* and presumably us as well. Our job is to clear it for the next
+* preemption after reset, otherwise that and future preemptions
+* will never complete. We'll just clear it every time.
+*/
+   stage_desc->attribute &= ~GUC_STAGE_DESC_ATTR_TERMINATED;
+
data[0] = INTEL_GUC_ACTION_REQUEST_PREEMPTION;
data[1] = client->stage_id;
data[2] = INTEL_GUC_PREEMPT_OPTION_DROP_WORK_Q |
-- 
2.14.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Here goes drm-intel-fixes-2017-11-01.

Fixes for Stable:

- Fix KBL Blank Screen (Jani)
- Fix FIFO Underrun on SNB (Maarten)

Other fixes:

- Fix GPU Hang on i915gm (Chris)
- Fix gem_tiled_pread_pwrite IGT case (Chris)
- Cancel modeset retry work during modeset clean-up (Manasi)

Thanks,
Rodrigo.

The following changes since commit 0b07194bb55ed836c2cc7c22e866b87a14681984:

  Linux 4.14-rc7 (2017-10-29 13:58:38 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2017-11-01

for you to fetch changes up to bb5cf3386327c9cb5ca3fbb85242e940751649c8:

  drm/i915: Check incoming alignment for unfenced buffers (on i915gm) 
(2017-11-01 10:28:28 -0700)


drm-intel-fixes-2017-11-01:

Fixes for Stable:

- Fix KBL Blank Screen (Jani)
- Fix FIFO Underrun on SNB (Maarten)

Other fixes:

- Fix GPU Hang on i915gm (Chris)
- Fix gem_tiled_pread_pwrite IGT case (Chris)
- Cancel modeset retry work during modeset clean-up (Manasi)


Chris Wilson (3):
  drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects)
  drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr)
  drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

Jani Nikula (1):
  drm/i915/edp: read edp display control registers unconditionally

Maarten Lankhorst (1):
  drm/i915: Do not rely on wm preservation for ILK watermarks

Manasi Navare (1):
  drm/i915: Cancel the modeset retry work during modeset cleanup

 drivers/gpu/drm/i915/i915_gem.c|  2 ++
 drivers/gpu/drm/i915/i915_gem_context.c|  2 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  4 +++
 drivers/gpu/drm/i915/intel_display.c   | 19 ++-
 drivers/gpu/drm/i915/intel_dp.c| 13 ++--
 drivers/gpu/drm/i915/intel_drv.h   |  1 -
 drivers/gpu/drm/i915/intel_pm.c| 51 --
 7 files changed, 57 insertions(+), 35 deletions(-)
___
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: drm_plane_helper_check_state() related stuff (rev3)

[Patchwork]

== Series Details ==

Series: drm: drm_plane_helper_check_state() related stuff (rev3)
URL   : https://patchwork.freedesktop.org/series/33002/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (shard-hsw) fdo#102707
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-hsw) fdo#102254

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-hswtotal:2539 pass:1431 dwarn:2   dfail:0   fail:9   skip:1097 
time:9286s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6304/shards.html
___
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: Implement ReadHitWriteOnlyDisable.

[Patchwork]

== Series Details ==

Series: drm/i915: Implement ReadHitWriteOnlyDisable.
URL   : https://patchwork.freedesktop.org/series/32991/
State : success

== Summary ==

Series 32991v1 drm/i915: Implement ReadHitWriteOnlyDisable.
https://patchwork.freedesktop.org/api/1.0/series/32991/revisions/1/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:447s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:456s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:382s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:508s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:490s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:557s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:442s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:585s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:492s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:425s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:496s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:586s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:567s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:649s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:520s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:458s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:571s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:423s

7da46c0a019ebaec3f67a8a6ccc60a56c2d521b1 drm-tip: 2017y-11m-01d-17h-32m-50s UTC 
integration manifest
b474a1ebd14f drm/i915: Implement ReadHitWriteOnlyDisable.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6306/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Implement ReadHitWriteOnlyDisable.

[Rafael Antognolli]

On Wed, Nov 01, 2017 at 02:11:05PM -0700, Rodrigo Vivi wrote:
> On Wed, Nov 01, 2017 at 04:32:35PM +, Rafael Antognolli wrote:
> > The workaround for this is described as:
> > 
> > "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if
> > RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1"
> > 
> > So it looks like the userspace should be responsible for setting these,
> > based on the number of multisamples dependency. However, the register
> > that controls RCC clock gating is not a context register, and cannot be
> > set by userspace.
> > 
> > Since we would end up setting one or another based on the number of
> > multisamples anyway, it seems harmless to just set both all the time.
> > 
> > This change (specially the GEN10_READ_HIT_WRITEONLY_DISABLE bit)
> 
> I wonder if we shouldn't stay only with this bit. For me it looks like
> one or another.

I would say we need at least the GEN10_READ_HIT_WRITEONLY_DISABLE bit, and then
we can decide if we are adding the other one or not. Within the same
program (I think sometimes even within a single draw call), it's
possible that we have some surfaces that are multisampled while others
are not, so in that case we would probably have to set both anyway.

However, I don't have a test case that proves that the workaround for
the multisampled case is required...

> > improves CNL stability by avoiding some of the hangs seen in the
> > platform.
> 
> But this is what matters. If this is the safest option for us
> let's do it.
> 
> > 
> > Signed-off-by: Rafael Antognolli 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h| 2 ++
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 8c775e96b4e4..d9a65cebefaa 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3837,6 +3837,7 @@ enum {
> >   */
> >  #define SLICE_UNIT_LEVEL_CLKGATE   _MMIO(0x94d4)
> >  #define  SARBUNIT_CLKGATE_DIS  (1 << 5)
> > +#define  RCCUNIT_CLKGATE_DIS   (1 << 7)
> >  
> >  /*
> >   * Display engine regs
> > @@ -7016,6 +7017,7 @@ enum {
> >  #define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
> >  # define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
> >  # define GEN9_RHWO_OPTIMIZATION_DISABLE(1<<14)
> > +# define GEN10_READ_HIT_WRITEONLY_DISABLE  (1<<14)
> 
> I don't believe you need to redefine this.
> It is same as GEN9_RHWO_OPTIMIZATION_DISABLE.
> 
> RCC Read Hit Write Only Optimization Disabled, SKL+ o spec.

Oh, I haven't noticed that! Will fix it in the next version...

> >  #define COMMON_SLICE_CHICKEN2  _MMIO(0x7014)
> >  # define GEN9_PBE_COMPRESSED_HASH_SELECTION(1<<13)
> >  # define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE (1<<12)
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index f31f2d6384c3..0d8e25a4623a 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -1320,6 +1320,11 @@ static int cnl_init_workarounds(struct 
> > intel_engine_cs *engine)
> > WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> > GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
> >  
> > +   /* ReadHitWriteOnlyDisable: cnl */
> 
> I was going to complain about the name but I saw on bspec it is really
> ReadHitWriteOnlyDisable while on wa_database it is WaReadHitWriteOnlyDisable
> 
> I would tend to prefer the second one, but with the first one the search on 
> Bspec works
> and search on wa_database also works... while second one it would be found on 
> BSpec.
> So let it be: ReadHitWriteOnlyDisable
> 
> Thanks,
> Rodrigo.
> 
> > +   WA_SET_BIT_MASKED(GEN7_COMMON_SLICE_CHICKEN1,
> > + GEN10_READ_HIT_WRITEONLY_DISABLE);
> > +   WA_SET_BIT_MASKED(SLICE_UNIT_LEVEL_CLKGATE, RCCUNIT_CLKGATE_DIS);
> > +
> 
> > /* WaEnablePreemptionGranularityControlByUMD:cnl */
> > I915_WRITE(GEN7_FF_SLICE_CS_CHICKEN1,
> >_MASKED_BIT_ENABLE(GEN9_FFSC_PERCTX_PREEMPT_CTRL));
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Flush the irq and tasklets before asserting engine is idle

[Patchwork]

== Series Details ==

Series: drm/i915: Flush the irq and tasklets before asserting engine is idle
URL   : https://patchwork.freedesktop.org/series/33009/
State : warning

== Summary ==

Series 33009v1 drm/i915: Flush the irq and tasklets before asserting engine is 
idle
https://patchwork.freedesktop.org/api/1.0/series/33009/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (fi-hsw-4770r)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:459s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:532s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:511s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:491s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:553s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:428s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:262s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:575s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:493s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:426s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:488s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:488s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:583s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:577s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:595s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:648s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:524s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:570s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:417s

7da46c0a019ebaec3f67a8a6ccc60a56c2d521b1 drm-tip: 2017y-11m-01d-17h-32m-50s UTC 
integration manifest
2bbc20c28589 drm/i915: Flush the irq and tasklets before asserting engine is 
idle

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6305/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/cnl: Symmetric scalers for each pipe

[Rodrigo Vivi]

On Wed, Nov 01, 2017 at 10:08:50AM +, Mika Kahola wrote:
> For Cannonlake the number of scalers for each pipe is 2. Let's increase
> the number of scalers for pipe C.
> 
> v2: Use INTEL_GEN() instead of IS_CANNONLAKE()
> 
> Signed-off-by: Mika Kahola 

also... merged to dinq already.
thanks for the patch.

> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 875d428..db03d17 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -347,7 +347,10 @@ void intel_device_info_runtime_init(struct 
> drm_i915_private *dev_priv)
>   struct intel_device_info *info = mkwrite_device_info(dev_priv);
>   enum pipe pipe;
>  
> - if (INTEL_GEN(dev_priv) >= 9) {
> + if (INTEL_GEN(dev_priv) >= 10) {
> + for_each_pipe(dev_priv, pipe)
> + info->num_scalers[pipe] = 2;
> + } else if (INTEL_GEN(dev_priv) == 9) {
>   info->num_scalers[PIPE_A] = 2;
>   info->num_scalers[PIPE_B] = 2;
>   info->num_scalers[PIPE_C] = 1;
> -- 
> 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] [PATCH v2] drm/i915/cnl: Symmetric scalers for each pipe

[Rodrigo Vivi]

On Wed, Nov 01, 2017 at 10:08:50AM +, Mika Kahola wrote:
> For Cannonlake the number of scalers for each pipe is 2. Let's increase
> the number of scalers for pipe C.
> 
> v2: Use INTEL_GEN() instead of IS_CANNONLAKE()
> 
> Signed-off-by: Mika Kahola 

Reviewed-by: Rodrigo Vivi 


> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 875d428..db03d17 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -347,7 +347,10 @@ void intel_device_info_runtime_init(struct 
> drm_i915_private *dev_priv)
>   struct intel_device_info *info = mkwrite_device_info(dev_priv);
>   enum pipe pipe;
>  
> - if (INTEL_GEN(dev_priv) >= 9) {
> + if (INTEL_GEN(dev_priv) >= 10) {
> + for_each_pipe(dev_priv, pipe)
> + info->num_scalers[pipe] = 2;
> + } else if (INTEL_GEN(dev_priv) == 9) {
>   info->num_scalers[PIPE_A] = 2;
>   info->num_scalers[PIPE_B] = 2;
>   info->num_scalers[PIPE_C] = 1;
> -- 
> 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] ✗ Fi.CI.IGT: failure for drm/i915: Implement ReadHitWriteOnlyDisable.

[Rodrigo Vivi]

On Wed, Nov 01, 2017 at 08:56:59PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Implement ReadHitWriteOnlyDisable.
> URL   : https://patchwork.freedesktop.org/series/32991/
> State : failure
> 
> == Summary ==
> 
> Test kms_flip:
> Subgroup plain-flip-fb-recreate-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#100368
> Subgroup modeset-vs-vblank-race-interruptible:
> fail   -> PASS   (shard-hsw) fdo#103060
> Test kms_setmode:
> Subgroup basic:
> fail   -> PASS   (shard-hsw) fdo#99912
> Test perf:
> Subgroup oa-exponents:
> fail   -> PASS   (shard-hsw) fdo#102254
> Test drv_module_reload:
> Subgroup basic-reload:
> pass   -> DMESG-WARN (shard-hsw) fdo#102707
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-pri-indfb-multidraw:
> pass   -> FAIL   (shard-hsw)

A false positive here. I triggered the patch retest. Altough we don't
cnl on full igt run anyways...

> 
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
> fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
> fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
> fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
> 
> shard-hswtotal:2539 pass:1430 dwarn:2   dfail:0   fail:10  skip:1097 
> time:9227s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6300/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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Don't try to use negative pll_id.

[Patchwork]

== Series Details ==

Series: drm/i915: Don't try to use negative pll_id.
URL   : https://patchwork.freedesktop.org/series/33004/
State : failure

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
pass   -> FAIL   (shard-hsw)
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-hsw) fdo#102254
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (shard-hsw) fdo#102707
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-hswtotal:2539 pass:1430 dwarn:2   dfail:0   fail:10  skip:1097 
time:9225s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6303/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: Implement ReadHitWriteOnlyDisable.

[Rodrigo Vivi]

On Wed, Nov 01, 2017 at 04:32:35PM +, Rafael Antognolli wrote:
> The workaround for this is described as:
> 
> "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if
> RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1"
> 
> So it looks like the userspace should be responsible for setting these,
> based on the number of multisamples dependency. However, the register
> that controls RCC clock gating is not a context register, and cannot be
> set by userspace.
> 
> Since we would end up setting one or another based on the number of
> multisamples anyway, it seems harmless to just set both all the time.
> 
> This change (specially the GEN10_READ_HIT_WRITEONLY_DISABLE bit)

I wonder if we shouldn't stay only with this bit. For me it looks like
one or another.

> improves CNL stability by avoiding some of the hangs seen in the
> platform.

But this is what matters. If this is the safest option for us
let's do it.

> 
> Signed-off-by: Rafael Antognolli 
> ---
>  drivers/gpu/drm/i915/i915_reg.h| 2 ++
>  drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8c775e96b4e4..d9a65cebefaa 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3837,6 +3837,7 @@ enum {
>   */
>  #define SLICE_UNIT_LEVEL_CLKGATE _MMIO(0x94d4)
>  #define  SARBUNIT_CLKGATE_DIS(1 << 5)
> +#define  RCCUNIT_CLKGATE_DIS (1 << 7)
>  
>  /*
>   * Display engine regs
> @@ -7016,6 +7017,7 @@ enum {
>  #define GEN7_COMMON_SLICE_CHICKEN1   _MMIO(0x7010)
>  # define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC   ((1<<10) | (1<<26))
>  # define GEN9_RHWO_OPTIMIZATION_DISABLE  (1<<14)
> +# define GEN10_READ_HIT_WRITEONLY_DISABLE(1<<14)

I don't believe you need to redefine this.
It is same as GEN9_RHWO_OPTIMIZATION_DISABLE.

RCC Read Hit Write Only Optimization Disabled, SKL+ o spec.

>  #define COMMON_SLICE_CHICKEN2_MMIO(0x7014)
>  # define GEN9_PBE_COMPRESSED_HASH_SELECTION  (1<<13)
>  # define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE (1<<12)
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index f31f2d6384c3..0d8e25a4623a 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1320,6 +1320,11 @@ static int cnl_init_workarounds(struct intel_engine_cs 
> *engine)
>   WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
>   GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
>  
> + /* ReadHitWriteOnlyDisable: cnl */

I was going to complain about the name but I saw on bspec it is really
ReadHitWriteOnlyDisable while on wa_database it is WaReadHitWriteOnlyDisable

I would tend to prefer the second one, but with the first one the search on 
Bspec works
and search on wa_database also works... while second one it would be found on 
BSpec.
So let it be: ReadHitWriteOnlyDisable

Thanks,
Rodrigo.

> + WA_SET_BIT_MASKED(GEN7_COMMON_SLICE_CHICKEN1,
> +   GEN10_READ_HIT_WRITEONLY_DISABLE);
> + WA_SET_BIT_MASKED(SLICE_UNIT_LEVEL_CLKGATE, RCCUNIT_CLKGATE_DIS);
> +

>   /* WaEnablePreemptionGranularityControlByUMD:cnl */
>   I915_WRITE(GEN7_FF_SLICE_CS_CHICKEN1,
>  _MASKED_BIT_ENABLE(GEN9_FFSC_PERCTX_PREEMPT_CTRL));
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: drm_plane_helper_check_state() related stuff (rev3)

[Patchwork]

== Series Details ==

Series: drm: drm_plane_helper_check_state() related stuff (rev3)
URL   : https://patchwork.freedesktop.org/series/33002/
State : success

== Summary ==

Series 33002v3 drm: drm_plane_helper_check_state() related stuff
https://patchwork.freedesktop.org/api/1.0/series/33002/revisions/3/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Subgroup common-hpd-after-suspend:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#102505
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-glk-dsi) fdo#103167

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:459s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:378s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:510s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:487s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:546s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:269s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:586s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:424s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:264  dwarn:0   dfail:0   fail:1   skip:24  
time:475s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:580s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:574s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:652s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:571s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:426s

7da46c0a019ebaec3f67a8a6ccc60a56c2d521b1 drm-tip: 2017y-11m-01d-17h-32m-50s UTC 
integration manifest
5fd2ee28cd29 drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c
f5a1386e738b drm: Check crtc_state->enable rather than crtc->enabled in 
drm_plane_helper_check_state()
9b967ad53783 drm/vmwgfx: Try to fix plane clipping
6fb4866d13f0 drm/vmwgfx: Use drm_plane_helper_check_state()
488c96ed9533 drm/vmwgfx: Remove bogus crtc coords vs fb size check

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6304/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Implement ReadHitWriteOnlyDisable.

[Patchwork]

== Series Details ==

Series: drm/i915: Implement ReadHitWriteOnlyDisable.
URL   : https://patchwork.freedesktop.org/series/32991/
State : failure

== Summary ==

Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-hsw) fdo#102254
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (shard-hsw) fdo#102707
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-pri-indfb-multidraw:
pass   -> FAIL   (shard-hsw)

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707

shard-hswtotal:2539 pass:1430 dwarn:2   dfail:0   fail:10  skip:1097 
time:9227s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6300/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Add support for reset engine using GuC commands

[Jeff McGee]

On Wed, Nov 01, 2017 at 01:58:04PM +, Chris Wilson wrote:
> Quoting Michel Thierry (2017-10-31 22:53:09)
> > This patch adds per engine reset and recovery (TDR) support when GuC is
> > used to submit workloads to GPU.
> > 
> > In the case of i915 directly submission to ELSP, driver manages hang
> > detection, recovery and resubmission. With GuC submission these tasks
> > are shared between driver and GuC. i915 is still responsible for detecting
> > a hang, and when it does it only requests GuC to reset that Engine. GuC
> > internally manages acquiring forcewake and idling the engine before
> > resetting it.
> > 
> > Once the reset is successful, i915 takes over again and handles the
> > resubmission. The scheduler in i915 knows which requests are pending so
> > after resetting a engine, pending workloads/requests are resubmitted
> > again.
> > 
> > v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the
> > non-guc function names.
> > 
> > v3: Removed debug message about engine restarting from which request,
> > since the new baseline do it regardless of submission mode. (Chris)
> > 
> > v4: Rebase.
> > 
> > v5: Do not pass unnecessary reporting flags to the fw (Jeff);
> > tasklet_schedule(>irq_tasklet) handles the resubmit; rebase.
> > 
> > v6: Rename the existing reset engine function and share a similar
> > interface between guc and non-guc paths (Chris).
> > 
> > Signed-off-by: Michel Thierry 
> > Cc: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c   | 15 +--
> >  drivers/gpu/drm/i915/i915_drv.h   |  2 ++
> >  drivers/gpu/drm/i915/intel_guc.c  | 24 
> >  drivers/gpu/drm/i915/intel_guc_fwif.h |  1 +
> >  drivers/gpu/drm/i915/intel_uncore.c   |  5 -
> >  5 files changed, 40 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index af745749509c..359333a423cf 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1950,6 +1950,12 @@ void i915_reset(struct drm_i915_private *i915, 
> > unsigned int flags)
> > goto finish;
> >  }
> >  
> > +static inline int intel_gt_reset_engine(struct drm_i915_private *dev_priv,
> > +   struct intel_engine_cs *engine)
> > +{
> > +   return intel_gpu_reset(dev_priv, intel_engine_flag(engine));
> > +}
> > +
> >  /**
> >   * i915_reset_engine - reset GPU engine to recover from a hang
> >   * @engine: engine to reset
> > @@ -1984,10 +1990,15 @@ int i915_reset_engine(struct intel_engine_cs 
> > *engine, unsigned int flags)
> > goto out;
> > }
> >  
> > -   ret = intel_gpu_reset(engine->i915, intel_engine_flag(engine));
> > +   if (!engine->i915->guc.execbuf_client)
> > +   ret = intel_gt_reset_engine(engine->i915, engine);
> > +   else
> > +   ret = intel_guc_reset_engine(>i915->guc, engine);
> > +
> > if (ret) {
> > /* If we fail here, we expect to fallback to a global reset 
> > */
> > -   DRM_DEBUG_DRIVER("Failed to reset %s, ret=%d\n",
> > +   DRM_DEBUG_DRIVER("%sFailed to reset %s, ret=%d\n",
> > +(engine->i915->guc.execbuf_client ? "GUC 
> > ":""),
> 
> A bit overkill on the parentheses there ;)
> 
> Lgtm, can you please ping, say, Jeff or Daniele for an r-b on the guc
> interaction?
> -Chris

There is one small change needed in the GuC preemption protocol to make it
compatible with GuC engine reset. I will send that shortly.

There are also a couple of corner case bugs with engine reset in our current
firmware versions. We are planning a firmware update to address those. But
the host-side code here is fine. So...

Reviewed-by: Jeff McGee 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Flush the irq and tasklets before asserting engine is idle

[Chris Wilson]

Before we assert that the engine is idle, make sure we flush any
residual tasklet. After that point, if the engine is not idle, more work
may be queued despite us trying to park the engine and go to sleep.

References: https://bugs.freedesktop.org/show_bug.cgi?id=103479
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0f8c542f0af2..70eeafe8a6ec 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1542,6 +1542,10 @@ void intel_engines_park(struct drm_i915_private *i915)
enum intel_engine_id id;
 
for_each_engine(engine, i915, id) {
+   /* Flush the residual irq tasklets first. */
+   intel_engine_disarm_breadcrumbs(engine);
+   tasklet_kill(>execlists.irq_tasklet);
+
/*
 * We are committed now to parking the engines, make sure there
 * will be no more interrupts arriving later and the engines
@@ -1558,9 +1562,6 @@ void intel_engines_park(struct drm_i915_private *i915)
if (engine->park)
engine->park(engine);
 
-   intel_engine_disarm_breadcrumbs(engine);
-   tasklet_kill(>execlists.irq_tasklet);
-
i915_gem_batch_pool_fini(>batch_pool);
engine->execlists.no_priolist = false;
}
-- 
2.15.0.rc2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 5/5] drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c

[Ville Syrjala]

From: Ville Syrjälä 

drm_plane_helper_check_update() isn't a transitional helper, so let's
rename it to drm_atomic_helper_check_plane_state() and move it into
drm_atomic_helper.c.

v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc

Cc: Daniel Vetter 
Suggested-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c|   8 +--
 drivers/gpu/drm/arm/malidp_planes.c |   4 +-
 drivers/gpu/drm/drm_atomic_helper.c |  94 +
 drivers/gpu/drm/drm_plane_helper.c  | 102 ++--
 drivers/gpu/drm/drm_simple_kms_helper.c |   9 +--
 drivers/gpu/drm/i915/intel_display.c|  22 +++---
 drivers/gpu/drm/imx/ipuv3-plane.c   |   8 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|   8 +--
 drivers/gpu/drm/meson/meson_plane.c |   8 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   5 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  20 +++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
 drivers/gpu/drm/tegra/dc.c  |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   8 +--
 drivers/gpu/drm/zte/zx_plane.c  |  15 ++--
 include/drm/drm_atomic_helper.h |   7 ++
 include/drm/drm_plane_helper.h  |   6 --
 17 files changed, 169 insertions(+), 165 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 14721723fa8a..63511a3bbf6c 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -252,10 +252,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
*plane,
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
 
-   return drm_plane_helper_check_state(state, crtc_state, ,
-   DRM_PLANE_HELPER_NO_SCALING,
-   DRM_PLANE_HELPER_NO_SCALING,
-   false, true);
+   return drm_atomic_helper_check_plane_state(state, crtc_state, ,
+  DRM_PLANE_HELPER_NO_SCALING,
+  DRM_PLANE_HELPER_NO_SCALING,
+  false, true);
 }
 
 static void hdlcd_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 492d99dd55d4..72a07950167e 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -150,8 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
 
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
-   ret = drm_plane_helper_check_state(state, crtc_state, ,
-  0, INT_MAX, true, true);
+   ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
+ 0, INT_MAX, true, true);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f1b56a..a381913c894d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -696,6 +696,100 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
 
 /**
+ * drm_atomic_helper_check_plane_state() - Check plane state for validity
+ * @plane_state: plane state to check
+ * @crtc_state: crtc state to check
+ * @clip: integer clipping coordinates
+ * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
+ * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
+ * @can_position: is it legal to position the plane such that it
+ *doesn't cover the entire crtc?  This will generally
+ *only be false for primary planes.
+ * @can_update_disabled: can the plane be updated while the crtc
+ *   is disabled?
+ *
+ * Checks that a desired plane update is valid, and updates various
+ * bits of derived state (clipped coordinates etc.). Drivers that provide
+ * their own plane handling rather than helper-provided implementations may
+ * still wish to call this function to avoid duplication of error checking
+ * code.
+ *
+ * RETURNS:
+ * Zero if update appears valid, error code on failure
+ */
+int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
+   const struct drm_crtc_state *crtc_state,
+   const struct drm_rect *clip,
+   int min_scale,
+   int max_scale,
+   bool can_position,
+   

[Intel-gfx] [PATCH v2 4/5] drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state()

[Ville Syrjala]

From: Ville Syrjälä 

drm_plane_helper_check_state() is supposed to do things the atomic way,
so it should not be inspecting crtc->enabled. Rather we should be
looking at crtc_state->enable.

We have a slight complication due to drm_plane_helper_check_update()
reusing drm_plane_helper_check_state() for non-atomic drivers. Thus
we'll have to pass the crtc_state in manally and construct a fake
crtc_state in drm_plane_helper_check_update().

v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c|  2 +-
 drivers/gpu/drm/arm/malidp_planes.c |  3 +-
 drivers/gpu/drm/drm_plane_helper.c  | 51 -
 drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  2 ++
 drivers/gpu/drm/imx/ipuv3-plane.c   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 +--
 drivers/gpu/drm/nouveau/nv50_display.c  |  6 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
 drivers/gpu/drm/tegra/dc.c  |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  2 +-
 drivers/gpu/drm/zte/zx_plane.c  |  4 +--
 include/drm/drm_plane_helper.h  |  3 +-
 15 files changed, 52 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 72b22b805412..14721723fa8a 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -252,7 +252,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
 
-   return drm_plane_helper_check_state(state, ,
+   return drm_plane_helper_check_state(state, crtc_state, ,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 94e7e3fa3408..492d99dd55d4 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -150,7 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
 
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
-   ret = drm_plane_helper_check_state(state, , 0, INT_MAX, true, 
true);
+   ret = drm_plane_helper_check_state(state, crtc_state, ,
+  0, INT_MAX, true, true);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 759ed93f4ba8..eef0ffcd7ed5 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -101,7 +101,8 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
 
 /**
  * drm_plane_helper_check_state() - Check plane state for validity
- * @state: plane state to check
+ * @plane_state: plane state to check
+ * @crtc_state: crtc state to check
  * @clip: integer clipping coordinates
  * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
  * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
@@ -120,35 +121,37 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
  * RETURNS:
  * Zero if update appears valid, error code on failure
  */
-int drm_plane_helper_check_state(struct drm_plane_state *state,
+int drm_plane_helper_check_state(struct drm_plane_state *plane_state,
+const struct drm_crtc_state *crtc_state,
 const struct drm_rect *clip,
 int min_scale,
 int max_scale,
 bool can_position,
 bool can_update_disabled)
 {
-   struct drm_crtc *crtc = state->crtc;
-   struct drm_framebuffer *fb = state->fb;
-   struct drm_rect *src = >src;
-   struct drm_rect *dst = >dst;
-   unsigned int rotation = state->rotation;
+   struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_rect *src = _state->src;
+   struct drm_rect *dst = _state->dst;
+   unsigned int rotation = plane_state->rotation;
int hscale, vscale;
 
-   *src = drm_plane_state_src(state);
-   *dst = drm_plane_state_dest(state);
+   WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
+
+   *src = drm_plane_state_src(plane_state);
+   *dst = drm_plane_state_dest(plane_state);
 
if (!fb) {
-   state->visible = false;
+   plane_state->visible = false;
return 0;
}

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't try to use negative pll_id.

[Patchwork]

== Series Details ==

Series: drm/i915: Don't try to use negative pll_id.
URL   : https://patchwork.freedesktop.org/series/33004/
State : success

== Summary ==

Series 33004v1 drm/i915: Don't try to use negative pll_id.
https://patchwork.freedesktop.org/api/1.0/series/33004/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-read-no-prefault:
pass   -> DMESG-WARN (fi-bsw-n3050) fdo#103479

fdo#103479 https://bugs.freedesktop.org/show_bug.cgi?id=103479

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:461s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:385s
fi-bsw-n3050 total:289  pass:242  dwarn:1   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:274s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:508s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:488s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:556s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:426s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:262s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:584s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:495s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:440s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:422s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:492s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:573s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:564s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:587s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:645s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:461s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:571s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:423s

7da46c0a019ebaec3f67a8a6ccc60a56c2d521b1 drm-tip: 2017y-11m-01d-17h-32m-50s UTC 
integration manifest
5c1d9a6dbde3 drm/i915: Don't try to use negative pll_id.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6303/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: drm_plane_helper_check_state() related stuff

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 07:46:18PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm: drm_plane_helper_check_state() related stuff
> URL   : https://patchwork.freedesktop.org/series/33002/
> State : failure
> 
> == Summary ==
> 
> Series 33002v1 drm: drm_plane_helper_check_state() related stuff
> https://patchwork.freedesktop.org/api/1.0/series/33002/revisions/1/mbox/
> 
> Test chamelium:
> Subgroup dp-edid-read:
> pass   -> DMESG-WARN (fi-kbl-7500u) fdo#102672
> Subgroup dp-crc-fast:
> pass   -> DMESG-WARN (fi-kbl-7500u) fdo#102514
> Subgroup hdmi-edid-read:
> pass   -> DMESG-WARN (fi-skl-6700k)
> Subgroup hdmi-crc-fast:
> pass   -> DMESG-WARN (fi-skl-6700k)
> Subgroup common-hpd-after-suspend:
> pass   -> DMESG-WARN (fi-skl-6700k)

Thinko in my WARNs.

I guess it needs to be something like:
-   WARN_ON(!crtc_state != !plane_state->crtc);
-   WARN_ON(crtc_state && crtc_state->crtc != plane_state->crtc);
+   WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);

since we grab the crtc from the old plane state if the new plane state
doesn't have one. And thus the crtc state we pass around may refer to
the old crtc, not the new one (well, there won't be a new one in
those cases).

Although I'm not sure how sensible it is to use the crtc state of the
old crtc for state computation/checks in general. Feels a bit iffy
at least.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in addition to tags

[Deucher, Alexander]

> -Original Message-
> From: dim-tools [mailto:dim-tools-boun...@lists.freedesktop.org] On Behalf
> Of Sean Paul
> Sent: Wednesday, November 01, 2017 8:52 AM
> To: Gustavo Padovan
> Cc: Daniel Vetter; Intel Graphics Development; dim-
> to...@lists.freedesktop.org; dri-devel; Daniel Vetter
> Subject: Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in
> addition to tags
> 
> On Wed, Nov 1, 2017 at 7:12 AM, Gustavo Padovan 
> wrote:
> > 2017-10-31 Sean Paul :
> >
> >> On Tue, Oct 31, 2017 at 1:31 PM, Daniel Vetter  wrote:
> >> > On Tue, Oct 31, 2017 at 5:14 PM, Sean Paul 
> wrote:
> >> >> On Tue, Oct 31, 2017 at 4:27 AM, Jani Nikula
> >> >>  wrote:
> >> >>>
> >> >>> Reminder, we have this new list dim-to...@lists.freedesktop.org for
> >> >>> maintainer tools patches. Cc'd.
> >> >>>
> >> >>
> >> >> Ahh, cool. I didn't realize dim grew up!
> >> >>
> >> >>> On Mon, 30 Oct 2017, Sean Paul  wrote:
> >>  Expanding on Jani's work to sign tags, this patch adds signing for git
> >>  commit/am.
> >> >>>
> >> >>> I guess I'd like more rationale here. Is this something we should be
> >> >>> doing? Is anyone else doing this?
> >> >>>
> >> >>
> >> >> Sure thing. Signing commits allows Dave to use --verify-signatures
> >> >> when pulling. If something is not signed, we'll know it was either not
> >> >> applied with dim, or was altered on fdo (both warrant investigation).
> >> >>
> >> >> I suspect no one else is doing this since most trees are single
> >> >> maintainer, and it's not possible to sign commits via git send-email.
> >> >> Since we have the committer model, and a bunch of people with
> access
> >> >> to fdo and the tree, I think it's important to add this. Especially
> >> >> since we can do it in dim without overhead.
> >> >>
> >>  Signed-off-by: Sean Paul 
> >>  ---
> >> 
> >>  This has been lightly tested with dim apply-branch/dim push-
> branch.
> >> 
> >>  Sean
> >> 
> >>   dim | 78
> +--
> --
> >>   1 file changed, 51 insertions(+), 27 deletions(-)
> >> 
> >>  diff --git a/dim b/dim
> >>  index 527989aff9ad..cd5e41f89a3a 100755
> >>  --- a/dim
> >>  +++ b/dim
> >>  @@ -67,9 +67,6 @@
> DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-
> $HOME/.dim.template.signature}
> >>   # dim pull-request tag summary template
> >> 
> DIM_TEMPLATE_TAG_SUMMARY=${DIM_TEMPLATE_TAG_SUMMARY:-
> $HOME/.dim.template.tagsummary}
> >> 
> >>  -# GPG key id for signing tags. If unset, don't sign.
> >>  -DIM_GPG_KEYID=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
> >>  -
> >>   #
> >>   # Internal configuration.
> >>   #
> >>  @@ -104,6 +101,20 @@ test_request_recipients=(
> >>   # integration configuration
> >>   integration_config=nightly.conf
> >> 
> >>  +# GPG key id for signing tags. If unset, don't sign.
> >>  +function gpg_keyid_for_tag
> >>  +{
> >>  + echo "${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}"
> >>  + return 0
> >>  +}
> >>  +
> >>  +# GPG key id for committing (git commit/am). If unset, don't sign.
> >>  +function gpg_keyid_for_commit
> >>  +{
> >>  + echo "${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}"
> >>  + return 0
> >>  +}
> >> >>>
> >> >>> This seems like an overly complicated way to achieve what you want.
> >> >>>
> >> >>> Just put these under "Internal configuration." instead:
> >> >>>
> >> >>> dim_gpg_sign_tag=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
> >> >>> dim_gpg_sign_commit=${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}
> >> >>>
> >> >>> And use directly in git tag and commit, respectively?
> >> >>>
> >> >>
> >> >> Yep, sounds good.
> >> >>
> >> >>> Although... perhaps starting to sign tags should not force signing
> >> >>> commits?
> >> >>>
> >> >>
> >> >> Why would it be desirable to *not* sign tags?
> >> >
> >> > Again, what's the threat model you're trying to defend against? Atm
> >> > anyone with commit rights to fd.o can push whatever they want to. If
> >> > they want to be evil, they can also push whatever kind of garbage they
> >> > want to, including commit signature and and fake Link: and review
> >> > tags. With pull requests/tags signing them prevents a
> >> > man-in-the-midddle attack of the unprotected pull request in the mail,
> >> > but I still don't see what signing commits protects against.
> >>
> >> This is protecting against a bad actor (either through a committer's
> >> account, or some other fdo account) gaining access to the tree on fdo
> >> and either adding a malicious commit, or altering an existing commit.
> >
> > Yeah, but then we need to enforce it for all committer
> 
> My hope is that dim makes it easy enough to get everyone on board
> eventually. In the interim, the people with signing commits 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: drm_plane_helper_check_state() related stuff

[Patchwork]

== Series Details ==

Series: drm: drm_plane_helper_check_state() related stuff
URL   : https://patchwork.freedesktop.org/series/33002/
State : failure

== Summary ==

Series 33002v1 drm: drm_plane_helper_check_state() related stuff
https://patchwork.freedesktop.org/api/1.0/series/33002/revisions/1/mbox/

Test chamelium:
Subgroup dp-edid-read:
pass   -> DMESG-WARN (fi-kbl-7500u) fdo#102672
Subgroup dp-crc-fast:
pass   -> DMESG-WARN (fi-kbl-7500u) fdo#102514
Subgroup hdmi-edid-read:
pass   -> DMESG-WARN (fi-skl-6700k)
Subgroup hdmi-crc-fast:
pass   -> DMESG-WARN (fi-skl-6700k)
Subgroup common-hpd-after-suspend:
pass   -> DMESG-WARN (fi-skl-6700k)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
pass   -> DMESG-WARN (fi-elk-e7500)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u) fdo#103285
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-glk-1)
pass   -> DMESG-WARN (fi-glk-dsi)
pass   -> DMESG-WARN (fi-cfl-s) fdo#103186
pass   -> DMESG-WARN (fi-cnl-y)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> DMESG-WARN (fi-gdg-551)
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-bwr-2160)
Test gem_busy:
Subgroup basic-hang-default:
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-blb-e6850)
pass   -> DMESG-WARN (fi-pnv-d510)
pass   -> DMESG-WARN (fi-elk-e7500)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-snb-2600) fdo#102365
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-FAIL (fi-kbl-7560u) fdo#103039
pass   -> DMESG-WARN (fi-kbl-7567u) fdo#102846 +11
pass   -> DMESG-WARN (fi-glk-1)
pass   -> DMESG-WARN (fi-glk-dsi)
pass   -> DMESG-WARN (fi-cnl-y)
   

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

[Rodrigo Vivi]

On Wed, Nov 01, 2017 at 07:08:52PM +, Manasi Navare wrote:
> On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote:
> > It is unlikely we are getting the -1 here.
> > But if we propagate that pll_id -1 to the rest of the code
> > we might have funny calculations on link_clock and who
> > knows what registers we end up accessing.
> > 
> > Better to protect the code.
> > 
> > Also better with errno number instead of generic -1.
> > 
> > Cc: Manasi Navare 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 10 ++
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c |  2 +-
> >  2 files changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index ace674cd79b9..2c6abdbf33ea 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1283,6 +1283,11 @@ static void cnl_ddi_clock_get(struct intel_encoder 
> > *encoder,
> >  
> > pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> >  
> > +   if (pll_id < 0) {
> > +   DRM_ERROR("PLL not found\n");
> > +   return;
> > +   }
> > +
> 
> The function intel_get_shared_dpll_id() already has this WARN_ON:
> if (WARN_ON(pll < dev_priv->shared_dplls))
> and it return pll_id = (pll - dev_priv->shared_dplls);
> So shouldnt this already throw a warning in case pll < dev_priv->shared_dplls 
> eventually
> resulting into a negative pll_id?

yeap, we through a warning and return -1.

Then we use the -1 to do some reg access and bits...

> 
> Manasi
> 
> > cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
> >  
> > if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
> > @@ -1337,6 +1342,11 @@ static void skl_ddi_clock_get(struct intel_encoder 
> > *encoder,
> >  
> > pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> >  
> > +   if (pll_id < 0) {
> > +   DRM_ERROR("PLL not found\n");
> > +   return;
> > +   }
> > +
> > dpll_ctl1 = I915_READ(DPLL_CTRL1);
> >  
> > if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(pll_id)) {
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index a83bf1c38e05..c4a7f39e173a 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -102,7 +102,7 @@ intel_get_shared_dpll_id(struct drm_i915_private 
> > *dev_priv,
> >  {
> > if (WARN_ON(pll < dev_priv->shared_dplls||
> > pll > _priv->shared_dplls[dev_priv->num_shared_dpll]))
> > -   return -1;
> > +   return -ENOENT;
> >  
> > return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
> >  }
> > -- 
> > 2.13.6
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 12:13:42PM -0700, Rodrigo Vivi wrote:
> On Wed, Nov 01, 2017 at 06:56:55PM +, Ville Syrjälä wrote:
> > On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote:
> > > It is unlikely we are getting the -1 here.
> > > But if we propagate that pll_id -1 to the rest of the code
> > > we might have funny calculations on link_clock and who
> > > knows what registers we end up accessing.
> > > 
> > > Better to protect the code.
> > > 
> > > Also better with errno number instead of generic -1.
> > > 
> > > Cc: Manasi Navare 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c  | 10 ++
> > >  drivers/gpu/drm/i915/intel_dpll_mgr.c |  2 +-
> > >  2 files changed, 11 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index ace674cd79b9..2c6abdbf33ea 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1283,6 +1283,11 @@ static void cnl_ddi_clock_get(struct intel_encoder 
> > > *encoder,
> > >  
> > >   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> > >  
> > > + if (pll_id < 0) {
> > > + DRM_ERROR("PLL not found\n");
> > > + return;
> > > + }
> > > +
> > >   cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
> > 
> > Don't we have the dpll state already read out?
> > 
> > crtc_state->dll_hw_state.cfgcr0 etc.?
> 
> oh! we do!
> Also during calc_wrpll_link we should be using this,
> shouldn't we?!
> 
> Probably my bad when doing this code looking to skl code...
> 
> Same thing on skl case, right?!

On all platforms I'd say. This is all probably just leftovers from before
we had the dpll manager.

I suspect we should just move all these foo_calc_wrpll_link() etc.
functions into the dpll manager. Not sure if we could just directly
fill out the port_clock in the dpll manager actually. Hmm. I guess not
in the .get_hw_state() at least since we don't pass the full crtc state
there. But we could perhaps have some kind of .clock_get() function
that'd be similar to the i9xx/vlv/chv_clock_get(), except we'd just call
it from the DDI code where we currently call these hand rolled
functions.

> > 
> > >  
> > >   if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
> > > @@ -1337,6 +1342,11 @@ static void skl_ddi_clock_get(struct intel_encoder 
> > > *encoder,
> > >  
> > >   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> > >  
> > > + if (pll_id < 0) {
> > > + DRM_ERROR("PLL not found\n");
> > > + return;
> > > + }
> > > +
> > >   dpll_ctl1 = I915_READ(DPLL_CTRL1);
> > >  
> > >   if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(pll_id)) {
> > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > index a83bf1c38e05..c4a7f39e173a 100644
> > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > @@ -102,7 +102,7 @@ intel_get_shared_dpll_id(struct drm_i915_private 
> > > *dev_priv,
> > >  {
> > >   if (WARN_ON(pll < dev_priv->shared_dplls||
> > >   pll > _priv->shared_dplls[dev_priv->num_shared_dpll]))
> > > - return -1;
> > > + return -ENOENT;
> > >  
> > >   return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
> > >  }
> > > -- 
> > > 2.13.6
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Ignore previous watermarks on ILK if inherited

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Ignore previous watermarks on ILK 
if inherited
URL   : https://patchwork.freedesktop.org/series/32995/
State : failure

== Summary ==

Series 32995 revision 1 was fully merged or fully failed: no git log

___
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: Implement ReadHitWriteOnlyDisable.

[Patchwork]

== Series Details ==

Series: drm/i915: Implement ReadHitWriteOnlyDisable.
URL   : https://patchwork.freedesktop.org/series/32991/
State : success

== Summary ==

Series 32991v1 drm/i915: Implement ReadHitWriteOnlyDisable.
https://patchwork.freedesktop.org/api/1.0/series/32991/revisions/1/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:449s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:457s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:531s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:508s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:510s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:491s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:567s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:264s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:590s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:495s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:428s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:500s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:573s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:590s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:572s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:520s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:457s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:572s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:418s

7da46c0a019ebaec3f67a8a6ccc60a56c2d521b1 drm-tip: 2017y-11m-01d-17h-32m-50s UTC 
integration manifest
e0e862794bb5 drm/i915: Implement ReadHitWriteOnlyDisable.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6300/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

[Rodrigo Vivi]

On Wed, Nov 01, 2017 at 06:56:55PM +, Ville Syrjälä wrote:
> On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote:
> > It is unlikely we are getting the -1 here.
> > But if we propagate that pll_id -1 to the rest of the code
> > we might have funny calculations on link_clock and who
> > knows what registers we end up accessing.
> > 
> > Better to protect the code.
> > 
> > Also better with errno number instead of generic -1.
> > 
> > Cc: Manasi Navare 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 10 ++
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c |  2 +-
> >  2 files changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index ace674cd79b9..2c6abdbf33ea 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1283,6 +1283,11 @@ static void cnl_ddi_clock_get(struct intel_encoder 
> > *encoder,
> >  
> > pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> >  
> > +   if (pll_id < 0) {
> > +   DRM_ERROR("PLL not found\n");
> > +   return;
> > +   }
> > +
> > cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
> 
> Don't we have the dpll state already read out?
> 
> crtc_state->dll_hw_state.cfgcr0 etc.?

oh! we do!
Also during calc_wrpll_link we should be using this,
shouldn't we?!

Probably my bad when doing this code looking to skl code...

Same thing on skl case, right?!

> 
> >  
> > if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
> > @@ -1337,6 +1342,11 @@ static void skl_ddi_clock_get(struct intel_encoder 
> > *encoder,
> >  
> > pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> >  
> > +   if (pll_id < 0) {
> > +   DRM_ERROR("PLL not found\n");
> > +   return;
> > +   }
> > +
> > dpll_ctl1 = I915_READ(DPLL_CTRL1);
> >  
> > if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(pll_id)) {
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index a83bf1c38e05..c4a7f39e173a 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -102,7 +102,7 @@ intel_get_shared_dpll_id(struct drm_i915_private 
> > *dev_priv,
> >  {
> > if (WARN_ON(pll < dev_priv->shared_dplls||
> > pll > _priv->shared_dplls[dev_priv->num_shared_dpll]))
> > -   return -1;
> > +   return -ENOENT;
> >  
> > return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
> >  }
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

[Manasi Navare]

On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote:
> It is unlikely we are getting the -1 here.
> But if we propagate that pll_id -1 to the rest of the code
> we might have funny calculations on link_clock and who
> knows what registers we end up accessing.
> 
> Better to protect the code.
> 
> Also better with errno number instead of generic -1.
> 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 10 ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |  2 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ace674cd79b9..2c6abdbf33ea 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1283,6 +1283,11 @@ static void cnl_ddi_clock_get(struct intel_encoder 
> *encoder,
>  
>   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
>  
> + if (pll_id < 0) {
> + DRM_ERROR("PLL not found\n");
> + return;
> + }
> +

The function intel_get_shared_dpll_id() already has this WARN_ON:
if (WARN_ON(pll < dev_priv->shared_dplls))
and it return pll_id = (pll - dev_priv->shared_dplls);
So shouldnt this already throw a warning in case pll < dev_priv->shared_dplls 
eventually
resulting into a negative pll_id?

Manasi

>   cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
>  
>   if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
> @@ -1337,6 +1342,11 @@ static void skl_ddi_clock_get(struct intel_encoder 
> *encoder,
>  
>   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
>  
> + if (pll_id < 0) {
> + DRM_ERROR("PLL not found\n");
> + return;
> + }
> +
>   dpll_ctl1 = I915_READ(DPLL_CTRL1);
>  
>   if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(pll_id)) {
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index a83bf1c38e05..c4a7f39e173a 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -102,7 +102,7 @@ intel_get_shared_dpll_id(struct drm_i915_private 
> *dev_priv,
>  {
>   if (WARN_ON(pll < dev_priv->shared_dplls||
>   pll > _priv->shared_dplls[dev_priv->num_shared_dpll]))
> - return -1;
> + return -ENOENT;
>  
>   return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
>  }
> -- 
> 2.13.6
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 11:44:58AM -0700, Rodrigo Vivi wrote:
> It is unlikely we are getting the -1 here.
> But if we propagate that pll_id -1 to the rest of the code
> we might have funny calculations on link_clock and who
> knows what registers we end up accessing.
> 
> Better to protect the code.
> 
> Also better with errno number instead of generic -1.
> 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 10 ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |  2 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ace674cd79b9..2c6abdbf33ea 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1283,6 +1283,11 @@ static void cnl_ddi_clock_get(struct intel_encoder 
> *encoder,
>  
>   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
>  
> + if (pll_id < 0) {
> + DRM_ERROR("PLL not found\n");
> + return;
> + }
> +
>   cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));

Don't we have the dpll state already read out?

crtc_state->dll_hw_state.cfgcr0 etc.?

>  
>   if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
> @@ -1337,6 +1342,11 @@ static void skl_ddi_clock_get(struct intel_encoder 
> *encoder,
>  
>   pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
>  
> + if (pll_id < 0) {
> + DRM_ERROR("PLL not found\n");
> + return;
> + }
> +
>   dpll_ctl1 = I915_READ(DPLL_CTRL1);
>  
>   if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(pll_id)) {
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index a83bf1c38e05..c4a7f39e173a 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -102,7 +102,7 @@ intel_get_shared_dpll_id(struct drm_i915_private 
> *dev_priv,
>  {
>   if (WARN_ON(pll < dev_priv->shared_dplls||
>   pll > _priv->shared_dplls[dev_priv->num_shared_dpll]))
> - return -1;
> + return -ENOENT;
>  
>   return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
>  }
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid and drivers: ELD refactoring

[Patchwork]

== Series Details ==

Series: drm/edid and drivers: ELD refactoring
URL   : https://patchwork.freedesktop.org/series/32979/
State : warning

== Summary ==

Series 32979v1 drm/edid and drivers: ELD refactoring
https://patchwork.freedesktop.org/api/1.0/series/32979/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test gem_mmap_gtt:
Subgroup basic-write:
pass   -> DMESG-WARN (fi-bsw-n3050)

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:458s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:383s
fi-bsw-n3050 total:289  pass:242  dwarn:1   dfail:0   fail:0   skip:46  
time:537s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:513s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:489s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:553s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:437s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:264s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:585s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:488s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:487s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:580s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:587s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:570s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:594s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:458s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:574s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:422s

7da46c0a019ebaec3f67a8a6ccc60a56c2d521b1 drm-tip: 2017y-11m-01d-17h-32m-50s UTC 
integration manifest
32c180fa26d0 drm/edid: make drm_edid_to_eld() static
66d925d9fff3 drm/drivers: drop redundant drm_edid_to_eld() calls
2e92d04c3df3 drm/edid: build ELD in drm_add_edid_modes()
44dd2571b79e drm/edid: abstract connector ELD clearing
75d70d77cad2 drm/i915: remove redundant ELD connector type update
f4fff201d6dc drm/edid: set ELD connector type in drm_edid_to_eld()
b8f8a0a3cdc6 drm/edid: use macros for ELD offsets and values

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6299/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Don't try to use negative pll_id.

[Rodrigo Vivi]

It is unlikely we are getting the -1 here.
But if we propagate that pll_id -1 to the rest of the code
we might have funny calculations on link_clock and who
knows what registers we end up accessing.

Better to protect the code.

Also better with errno number instead of generic -1.

Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 10 ++
 drivers/gpu/drm/i915/intel_dpll_mgr.c |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ace674cd79b9..2c6abdbf33ea 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1283,6 +1283,11 @@ static void cnl_ddi_clock_get(struct intel_encoder 
*encoder,
 
pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
 
+   if (pll_id < 0) {
+   DRM_ERROR("PLL not found\n");
+   return;
+   }
+
cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
 
if (cfgcr0 & DPLL_CFGCR0_HDMI_MODE) {
@@ -1337,6 +1342,11 @@ static void skl_ddi_clock_get(struct intel_encoder 
*encoder,
 
pll_id = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
 
+   if (pll_id < 0) {
+   DRM_ERROR("PLL not found\n");
+   return;
+   }
+
dpll_ctl1 = I915_READ(DPLL_CTRL1);
 
if (dpll_ctl1 & DPLL_CTRL1_HDMI_MODE(pll_id)) {
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index a83bf1c38e05..c4a7f39e173a 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -102,7 +102,7 @@ intel_get_shared_dpll_id(struct drm_i915_private *dev_priv,
 {
if (WARN_ON(pll < dev_priv->shared_dplls||
pll > _priv->shared_dplls[dev_priv->num_shared_dpll]))
-   return -1;
+   return -ENOENT;
 
return (enum intel_dpll_id) (pll - dev_priv->shared_dplls);
 }
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/5] drm: Check crtc_state->enable rather than crtc->enabled in drm_plane_helper_check_state()

[Ville Syrjala]

From: Ville Syrjälä 

drm_plane_helper_check_state() is supposed to do things the atomic way,
so it should not be inspecting crtc->enabled. Rather we should be
looking at crtc_state->enable.

We have a slight complication due to drm_plane_helper_check_update()
reusing drm_plane_helper_check_state() for non-atomic drivers. Thus
we'll have to pass the crtc_state in manally and construct a fake
crtc_state in drm_plane_helper_check_update().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c|  2 +-
 drivers/gpu/drm/arm/malidp_planes.c |  3 +-
 drivers/gpu/drm/drm_plane_helper.c  | 52 +
 drivers/gpu/drm/drm_simple_kms_helper.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  2 ++
 drivers/gpu/drm/imx/ipuv3-plane.c   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 +--
 drivers/gpu/drm/nouveau/nv50_display.c  |  6 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
 drivers/gpu/drm/tegra/dc.c  |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  2 +-
 drivers/gpu/drm/zte/zx_plane.c  |  4 +--
 include/drm/drm_plane_helper.h  |  3 +-
 15 files changed, 53 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 72b22b805412..14721723fa8a 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -252,7 +252,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane *plane,
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
 
-   return drm_plane_helper_check_state(state, ,
+   return drm_plane_helper_check_state(state, crtc_state, ,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 94e7e3fa3408..492d99dd55d4 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -150,7 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
 
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
-   ret = drm_plane_helper_check_state(state, , 0, INT_MAX, true, 
true);
+   ret = drm_plane_helper_check_state(state, crtc_state, ,
+  0, INT_MAX, true, true);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 759ed93f4ba8..adb8d94484f2 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -101,7 +101,8 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
 
 /**
  * drm_plane_helper_check_state() - Check plane state for validity
- * @state: plane state to check
+ * @plane_state: plane state to check
+ * @crtc_state: crtc state to check
  * @clip: integer clipping coordinates
  * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
  * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
@@ -120,35 +121,38 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
  * RETURNS:
  * Zero if update appears valid, error code on failure
  */
-int drm_plane_helper_check_state(struct drm_plane_state *state,
+int drm_plane_helper_check_state(struct drm_plane_state *plane_state,
+const struct drm_crtc_state *crtc_state,
 const struct drm_rect *clip,
 int min_scale,
 int max_scale,
 bool can_position,
 bool can_update_disabled)
 {
-   struct drm_crtc *crtc = state->crtc;
-   struct drm_framebuffer *fb = state->fb;
-   struct drm_rect *src = >src;
-   struct drm_rect *dst = >dst;
-   unsigned int rotation = state->rotation;
+   struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_rect *src = _state->src;
+   struct drm_rect *dst = _state->dst;
+   unsigned int rotation = plane_state->rotation;
int hscale, vscale;
 
-   *src = drm_plane_state_src(state);
-   *dst = drm_plane_state_dest(state);
+   WARN_ON(!crtc_state != !plane_state->crtc);
+   WARN_ON(crtc_state && crtc_state->crtc != plane_state->crtc);
+
+   *src = drm_plane_state_src(plane_state);
+   *dst = drm_plane_state_dest(plane_state);
 
if (!fb) {
-   state->visible = false;
+   plane_state->visible = false;
return 0;
}
 
/* crtc 

[Intel-gfx] [PATCH 5/5] drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c

[Ville Syrjala]

From: Ville Syrjälä 

drm_plane_helper_check_update() isn't a transitional helper, so let's
rename it to drm_atomic_helper_check_plane_state() and move it into
drm_atomic_helper.c.

Cc: Daniel Vetter 
Suggested-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/arm/hdlcd_crtc.c|   8 +--
 drivers/gpu/drm/arm/malidp_planes.c |   4 +-
 drivers/gpu/drm/drm_atomic_helper.c |  95 +
 drivers/gpu/drm/drm_plane_helper.c  | 103 ++--
 drivers/gpu/drm/drm_simple_kms_helper.c |   9 +--
 drivers/gpu/drm/i915/intel_display.c|  22 +++---
 drivers/gpu/drm/imx/ipuv3-plane.c   |   8 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|   8 +--
 drivers/gpu/drm/meson/meson_plane.c |   8 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   5 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  20 +++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
 drivers/gpu/drm/tegra/dc.c  |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   8 +--
 drivers/gpu/drm/zte/zx_plane.c  |  15 ++--
 include/drm/drm_atomic_helper.h |   7 ++
 include/drm/drm_plane_helper.h  |   6 --
 17 files changed, 170 insertions(+), 166 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 14721723fa8a..63511a3bbf6c 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -252,10 +252,10 @@ static int hdlcd_plane_atomic_check(struct drm_plane 
*plane,
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
 
-   return drm_plane_helper_check_state(state, crtc_state, ,
-   DRM_PLANE_HELPER_NO_SCALING,
-   DRM_PLANE_HELPER_NO_SCALING,
-   false, true);
+   return drm_atomic_helper_check_plane_state(state, crtc_state, ,
+  DRM_PLANE_HELPER_NO_SCALING,
+  DRM_PLANE_HELPER_NO_SCALING,
+  false, true);
 }
 
 static void hdlcd_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 492d99dd55d4..72a07950167e 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -150,8 +150,8 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
 
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
-   ret = drm_plane_helper_check_state(state, crtc_state, ,
-  0, INT_MAX, true, true);
+   ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
+ 0, INT_MAX, true, true);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f1b56a..7595ad8ad2f3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -696,6 +696,101 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
 
 /**
+ * drm_atomic_helper_check_plane_state() - Check plane state for validity
+ * @plane_state: plane state to check
+ * @crtc_state: crtc state to check
+ * @clip: integer clipping coordinates
+ * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
+ * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
+ * @can_position: is it legal to position the plane such that it
+ *doesn't cover the entire crtc?  This will generally
+ *only be false for primary planes.
+ * @can_update_disabled: can the plane be updated while the crtc
+ *   is disabled?
+ *
+ * Checks that a desired plane update is valid, and updates various
+ * bits of derived state (clipped coordinates etc.). Drivers that provide
+ * their own plane handling rather than helper-provided implementations may
+ * still wish to call this function to avoid duplication of error checking
+ * code.
+ *
+ * RETURNS:
+ * Zero if update appears valid, error code on failure
+ */
+int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
+   const struct drm_crtc_state *crtc_state,
+   const struct drm_rect *clip,
+   int min_scale,
+   int max_scale,
+   bool can_position,
+   bool can_update_disabled)
+{
+   struct 

[Intel-gfx] [PATCH 2/5] drm/vmwgfx: Use drm_plane_helper_check_state()

[Ville Syrjala]

From: Ville Syrjälä 

Atomic drivers have no reason to use drm_plane_helper_check_update()
instead of drm_plane_helper_check_state(). So let's switch over.

Cc: VMware Graphics 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a4b56699679a..515b67783a41 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -442,29 +442,18 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane 
*plane,
  struct drm_plane_state *state)
 {
struct drm_framebuffer *new_fb = state->fb;
-   bool visible;
-
-   struct drm_rect src = {
-   .x1 = state->src_x,
-   .y1 = state->src_y,
-   .x2 = state->src_x + state->src_w,
-   .y2 = state->src_y + state->src_h,
-   };
-   struct drm_rect dest = {
+   struct drm_rect clip = {
.x1 = state->crtc_x,
.y1 = state->crtc_y,
.x2 = state->crtc_x + state->crtc_w,
.y2 = state->crtc_y + state->crtc_h,
};
-   struct drm_rect clip = dest;
int ret;
 
-   ret = drm_plane_helper_check_update(plane, state->crtc, new_fb,
-   , , ,
-   DRM_MODE_ROTATE_0,
+   ret = drm_plane_helper_check_state(state, ,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
-   false, true, );
+   false, true);
 
 
if (!ret && new_fb) {
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping

[Ville Syrjala]

From: Ville Syrjälä 

Try to fix the code to actually clip the plane to the crtc bounds
instead of the user provided crtc coordinates (which would be a no-op
since those are exactly the coordinates before clipping).

Cc: VMware Graphics 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 515b67783a41..efa41c086198 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -441,20 +441,23 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane *plane,
 int vmw_du_primary_plane_atomic_check(struct drm_plane *plane,
  struct drm_plane_state *state)
 {
+   struct drm_crtc_state *crtc_state = NULL;
struct drm_framebuffer *new_fb = state->fb;
-   struct drm_rect clip = {
-   .x1 = state->crtc_x,
-   .y1 = state->crtc_y,
-   .x2 = state->crtc_x + state->crtc_w,
-   .y2 = state->crtc_y + state->crtc_h,
-   };
+   struct drm_rect clip = {};
int ret;
 
-   ret = drm_plane_helper_check_state(state, ,
-   DRM_PLANE_HELPER_NO_SCALING,
-   DRM_PLANE_HELPER_NO_SCALING,
-   false, true);
+   if (state->crtc)
+   crtc_state = drm_atomic_get_new_crtc_state(state->state, 
state->crtc);
 
+   if (crtc_state && crtc_state->enable) {
+   clip.x2 = crtc_state->adjusted_mode.hdisplay;
+   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   }
+
+   ret = drm_plane_helper_check_state(state, ,
+  DRM_PLANE_HELPER_NO_SCALING,
+  DRM_PLANE_HELPER_NO_SCALING,
+  false, true);
 
if (!ret && new_fb) {
struct drm_crtc *crtc = state->crtc;
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

[Ville Syrjala]

From: Ville Syrjälä 

While trawling the tree I spotted some issues with the way vmwgfx
uses drm_plane_helper_check_state(). Here's my attempt at fixing it.
Do note that I haven't actually tested the resulting code at all,
but it does build at least.

And while touching that general area I took up Daniel's suggestion from
long ago that drm_plane_helper_check_state() should be renamed and
relocated to better reflect its status.

Here's a branch with the entire series:
git://github.com/vsyrjala/linux.git atomic_helper_plane_stuff

Cc: VMware Graphics 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Cc: Daniel Vetter 

Ville Syrjälä (5):
  drm/vmwgfx: Remove bogus crtc coords vs fb size check
  drm/vmwgfx: Use drm_plane_helper_check_state()
  drm/vmwgfx: Try to fix plane clipping
  drm: Check crtc_state->enable rather than crtc->enabled in
drm_plane_helper_check_state()
  drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c

 drivers/gpu/drm/arm/hdlcd_crtc.c|   8 +-
 drivers/gpu/drm/arm/malidp_planes.c |   3 +-
 drivers/gpu/drm/drm_atomic_helper.c |  95 
 drivers/gpu/drm/drm_plane_helper.c  | 111 +++-
 drivers/gpu/drm/drm_simple_kms_helper.c |   9 ++-
 drivers/gpu/drm/i915/intel_display.c|  20 ++---
 drivers/gpu/drm/imx/ipuv3-plane.c   |   8 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|   8 +-
 drivers/gpu/drm/meson/meson_plane.c |   8 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   5 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  18 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
 drivers/gpu/drm/tegra/dc.c  |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  40 --
 drivers/gpu/drm/zte/zx_plane.c  |  15 ++--
 include/drm/drm_atomic_helper.h |   7 ++
 include/drm/drm_plane_helper.h  |   5 --
 17 files changed, 187 insertions(+), 183 deletions(-)

-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/5] drm/vmwgfx: Remove bogus crtc coords vs fb size check

[Ville Syrjala]

From: Ville Syrjälä 

Throw away the bugs crtc coords vs. fb size check. Crtc coords don't
define the viewport inside the fb, that's a job for the src coords,
which have been checked by the core already.

Cc: VMware Graphics 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 0545740b3724..a4b56699679a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -476,12 +476,6 @@ int vmw_du_primary_plane_atomic_check(struct drm_plane 
*plane,
 
vcs = vmw_connector_state_to_vcs(du->connector.state);
 
-   if ((dest.x2 > new_fb->width ||
-dest.y2 > new_fb->height)) {
-   DRM_ERROR("CRTC area outside of framebuffer\n");
-   return -EINVAL;
-   }
-
/* Only one active implicit framebuffer at a time. */
mutex_lock(_priv->global_kms_state_mutex);
if (vcs->is_implicit && dev_priv->implicit_fb &&
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm: Enable pr_debug() for drm_printer

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm: Enable pr_debug() for drm_printer
URL   : https://patchwork.freedesktop.org/series/32750/
State : success

== Summary ==

Series 32750v1 series starting with [1/4] drm: Enable pr_debug() for drm_printer
https://patchwork.freedesktop.org/api/1.0/series/32750/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test gem_ctx_switch:
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-glk-dsi)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-kbl-7567u) fdo#102846

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:503s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:492s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:555s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:432s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:586s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:486s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:483s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:573s
fi-kbl-7567u total:247  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:563s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:602s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:649s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:514s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:569s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:417s

fff06da054b4752eabf7d4103d30a281f8de96d9 drm-tip: 2017y-11m-01d-13h-47m-20s UTC 
integration manifest
51acb4270a75 drm/i915: Give more details for the active-when-parking warning 
for the engines
32fce6e3f7c2 drm/i915: Move parking-while-active warning to intel_engines_park()
202441ac4742 drm/i915: Enable pr_debug() for CI debugging

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6298/
___
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/drm_vma_manager.c: Remove useless goto statement

[Patchwork]

== Series Details ==

Series: drm/drm_vma_manager.c: Remove useless goto statement
URL   : https://patchwork.freedesktop.org/series/32987/
State : success

== Summary ==

Test kms_flip:
Subgroup flip-vs-blocking-wf-vblank:
fail   -> PASS   (shard-hsw)
Subgroup wf_vblank-vs-modeset-interruptible:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test gem_exec_suspend:
Subgroup basic-S4:
fail   -> SKIP   (shard-hsw)
Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (shard-hsw) fdo#102707

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707

shard-hswtotal:2539 pass:1432 dwarn:1   dfail:0   fail:8   skip:1098 
time:9224s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6296/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in addition to tags

[Sean Paul]

On Wed, Nov 1, 2017 at 1:00 PM, Eric Anholt  wrote:
> Sean Paul  writes:
>
>> On Wed, Nov 1, 2017 at 7:12 AM, Gustavo Padovan  wrote:
>>> 2017-10-31 Sean Paul :
>>>
 On Tue, Oct 31, 2017 at 1:31 PM, Daniel Vetter  wrote:
 > On Tue, Oct 31, 2017 at 5:14 PM, Sean Paul  wrote:
 >> On Tue, Oct 31, 2017 at 4:27 AM, Jani Nikula
 >>  wrote:
 >>>
 >>> Reminder, we have this new list dim-to...@lists.freedesktop.org for
 >>> maintainer tools patches. Cc'd.
 >>>
 >>
 >> Ahh, cool. I didn't realize dim grew up!
 >>
 >>> On Mon, 30 Oct 2017, Sean Paul  wrote:
  Expanding on Jani's work to sign tags, this patch adds signing for git
  commit/am.
 >>>
 >>> I guess I'd like more rationale here. Is this something we should be
 >>> doing? Is anyone else doing this?
 >>>
 >>
 >> Sure thing. Signing commits allows Dave to use --verify-signatures
 >> when pulling. If something is not signed, we'll know it was either not
 >> applied with dim, or was altered on fdo (both warrant investigation).
 >>
 >> I suspect no one else is doing this since most trees are single
 >> maintainer, and it's not possible to sign commits via git send-email.
 >> Since we have the committer model, and a bunch of people with access
 >> to fdo and the tree, I think it's important to add this. Especially
 >> since we can do it in dim without overhead.
 >>
  Signed-off-by: Sean Paul 
  ---
 
  This has been lightly tested with dim apply-branch/dim push-branch.
 
  Sean
 
   dim | 78 
  +
   1 file changed, 51 insertions(+), 27 deletions(-)
 
  diff --git a/dim b/dim
  index 527989aff9ad..cd5e41f89a3a 100755
  --- a/dim
  +++ b/dim
  @@ -67,9 +67,6 @@ 
  DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-$HOME/.dim.template.signature}
   # dim pull-request tag summary template
   
  DIM_TEMPLATE_TAG_SUMMARY=${DIM_TEMPLATE_TAG_SUMMARY:-$HOME/.dim.template.tagsummary}
 
  -# GPG key id for signing tags. If unset, don't sign.
  -DIM_GPG_KEYID=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
  -
   #
   # Internal configuration.
   #
  @@ -104,6 +101,20 @@ test_request_recipients=(
   # integration configuration
   integration_config=nightly.conf
 
  +# GPG key id for signing tags. If unset, don't sign.
  +function gpg_keyid_for_tag
  +{
  + echo "${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}"
  + return 0
  +}
  +
  +# GPG key id for committing (git commit/am). If unset, don't sign.
  +function gpg_keyid_for_commit
  +{
  + echo "${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}"
  + return 0
  +}
 >>>
 >>> This seems like an overly complicated way to achieve what you want.
 >>>
 >>> Just put these under "Internal configuration." instead:
 >>>
 >>> dim_gpg_sign_tag=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
 >>> dim_gpg_sign_commit=${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}
 >>>
 >>> And use directly in git tag and commit, respectively?
 >>>
 >>
 >> Yep, sounds good.
 >>
 >>> Although... perhaps starting to sign tags should not force signing
 >>> commits?
 >>>
 >>
 >> Why would it be desirable to *not* sign tags?
 >
 > Again, what's the threat model you're trying to defend against? Atm
 > anyone with commit rights to fd.o can push whatever they want to. If
 > they want to be evil, they can also push whatever kind of garbage they
 > want to, including commit signature and and fake Link: and review
 > tags. With pull requests/tags signing them prevents a
 > man-in-the-midddle attack of the unprotected pull request in the mail,
 > but I still don't see what signing commits protects against.

 This is protecting against a bad actor (either through a committer's
 account, or some other fdo account) gaining access to the tree on fdo
 and either adding a malicious commit, or altering an existing commit.
>>>
>>> Yeah, but then we need to enforce it for all committer
>>
>> My hope is that dim makes it easy enough to get everyone on board
>> eventually. In the interim, the people with signing commits will be
>> able to attest that those commits were applied by them.
>>
>>> and we also need
>>> a signing party to sign each others keys.
>>
>> I feel like most of us see each other often enough to make this
>> possible. Even without a signing party, we still get 

[Intel-gfx] [(RESEND for CI) PATCH 2/2] drm/i915: Re-enable fastboot by default

[Maarten Lankhorst]

This fix was originally reverted because it left a chromebook pixel
black, and no immediate fix was available. This has been fixed in the
meantime.

Rather than trying to remove the parameter, set it to default to true
for now, so we can always back out if required.

Signed-off-by: Maarten Lankhorst 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Testcase: kms_panel_fitting
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index e54e6a4bc6bd..396126aac932 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -57,7 +57,7 @@
param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \
param(bool, enable_cmd_parser, true) \
param(bool, enable_hangcheck, true) \
-   param(bool, fastboot, false) \
+   param(bool, fastboot, true) \
param(bool, prefault_disable, false) \
param(bool, load_detect_test, false) \
param(bool, force_reset_modeset_test, false) \
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Ignore previous watermarks on ILK if inherited

[Maarten Lankhorst]

Fixes the following error when fastset is enabled, caught by CI:

[drm:ilk_validate_wm_level.part.8 [i915]] Sprite WM0 too large 56 (max 0)
[drm:ilk_validate_pipe_wm [i915]] LP0 watermark invalid
[drm:intel_crtc_atomic_check [i915]] No valid intermediate pipe watermarks are 
possible

Triggered on debugfs_test.read_all_entries, but could have been any igt
test depending on ordering.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a01ec068eba8..05dbeb430e21 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3380,6 +3380,7 @@ static int ilk_compute_intermediate_wm(struct drm_device 
*dev,
 */
*a = newstate->wm.ilk.optimal;
if (!newstate->base.active || intel_state->skip_intermediate_wm ||
+   oldstate->base.mode.private_flags & I915_MODE_FLAG_INHERITED ||
drm_atomic_crtc_needs_modeset(>base))
return 0;
 
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Maarten Lankhorst]

Op 01-11-17 om 18:00 schreef Ville Syrjälä:
> On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
>> Op 01-11-17 om 16:29 schreef Ville Syrjälä:
>>> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
 This introduces a slight behavioral change to rmfb. Instead of
 disabling a crtc when the primary plane is disabled, we try to
 preserve it.

 Apart from old versions of the vmwgfx xorg driver, there is
 nothing depending on rmfb disabling a crtc.

 Vmwgfx' and simple kms helper atomic implementation rejects CRTC
 enabled without plane, so we can do this safely.
> The code for those seems a bit inconsistent. The crtc check requires
> that the crtc state and plane state match. But the plane check allows
> the plane to be enabled w/o the crtc being enabled. I guess it doesn't
> matter really since you can't enable the plane without a crtc, and the
> crtc check would then catch the case where the crtc would be disabled.
>
> Oh and looks like drm_plane_helper_check_state() is a bit buggy. It
> still uses crtc->enabled instead of crtc_state->enable to check the
> state of the crtc. I guess to keep drm_plane_helper_check_update()
> working we may have to pass in the crtc state manually.
This is the transitional helper. i915 gets away with it because it passes the 
flag that ignores crtc->enabled.
> The vmwgfx plane check looks a bit bogus in other ways too. I guess
> I'll have to fire off a couple of patches.
>
 If the atomic commit is rejected by the driver then we will still
 fall back to the old behavior and turn off the crtc.

 Changes since v1:
 - Restart completely when rmfb with crtc on fails (Sean Paul).

 Signed-off-by: Maarten Lankhorst 
 Cc: Sean Paul 
 Cc: Daniel Vetter 
 ---
  drivers/gpu/drm/drm_framebuffer.c | 23 +--
  1 file changed, 17 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/drm_framebuffer.c 
 b/drivers/gpu/drm/drm_framebuffer.c
 index 2affe53f3fda..f0679468f421 100644
 --- a/drivers/gpu/drm/drm_framebuffer.c
 +++ b/drivers/gpu/drm/drm_framebuffer.c
 @@ -765,14 +765,18 @@ static int atomic_remove_fb(struct drm_framebuffer 
 *fb)
struct drm_plane *plane;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
 -  int i, ret = 0;
 +  int i, ret;
unsigned plane_mask;
 +  bool disable_crtcs = false;
  
 -  state = drm_atomic_state_alloc(dev);
 -  if (!state)
 -  return -ENOMEM;
 -
 +retry_disable:
drm_modeset_acquire_init(, 0);
 +
 +  state = drm_atomic_state_alloc(dev);
 +  if (!state) {
 +  ret = -ENOMEM;
 +  goto out;
 +  }
state->acquire_ctx = 
  
  retry:
 @@ -793,7 +797,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
goto unlock;
}
  
 -  if (plane_state->crtc->primary == plane) {
 +  if (disable_crtcs && plane_state->crtc->primary == plane) {
struct drm_crtc_state *crtc_state;
  
crtc_state = drm_atomic_get_existing_crtc_state(state, 
 plane_state->crtc);
 @@ -818,6 +822,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
plane->old_fb = plane->fb;
}
  
 +  /* This list is only filled when disable_crtcs is set. */
for_each_new_connector_in_state(state, conn, conn_state, i) {
>>> WARN_ON(!disable_crtcs) maybe?
>> Would be overkill, nothing before it adds connector state, and if atomic 
>> check does then that's fine, but it won't be run here. :)
> It would serve as a way to document that fact, even without the comment.
> But I won't insist on it.
>
ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
  
 @@ -840,9 +845,15 @@ static int atomic_remove_fb(struct drm_framebuffer 
 *fb)
  
drm_atomic_state_put(state);
  
 +out:
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
  
 +  if (ret == -EINVAL && !disable_crtcs) {
>>> Hmm. -EINVAL seems rather specific. Not sure if we could just check for
>>> any error?
>>>
>>> Or... I'm not sure if we have any central place where we do the
>>> "can I disable the primary plane w/o disabling the crtc?" check. If we
>>> do then we could also add a comment there informing people that the
>>> -EINVAL is important.
>> We don't have a central place, I check for EINVAL since that is the generic 
>> atomic_check() failed error. If it fails for any other reason then we don't 
>> have to retry, but pass it along. :)
> Oh well. I guess people just have to be careful with their error
> values. I suppoe anyone depending on the retry will notice this
> issue rather quickly.
Yes. :)

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm: Enable pr_debug() for drm_printer

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm: Enable pr_debug() for drm_printer
URL   : https://patchwork.freedesktop.org/series/32750/
State : failure

== Summary ==

Series 32750v1 series starting with [1/4] drm: Enable pr_debug() for drm_printer
https://patchwork.freedesktop.org/api/1.0/series/32750/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test gem_ctx_switch:
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-glk-dsi)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
pass   -> FAIL   (fi-skl-6700k)
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-bsw-n3050)

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:452s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:242  dwarn:1   dfail:0   fail:0   skip:46  
time:536s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:505s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:485s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:554s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:266s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:583s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:497s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:434s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:481s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:570s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:596s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:640s
fi-skl-6700k total:289  pass:264  dwarn:0   dfail:0   fail:1   skip:24  
time:528s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:575s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:426s
fi-cnl-y failed to connect after reboot

fff06da054b4752eabf7d4103d30a281f8de96d9 drm-tip: 2017y-11m-01d-13h-47m-20s UTC 
integration manifest
e64b3c558c23 drm/i915: Give more details for the active-when-parking warning 
for the engines
f865e9dd5c67 drm/i915: Move parking-while-active warning to intel_engines_park()
9805b7162c02 drm/i915: Enable pr_debug() for CI debugging

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6297/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

[Rodrigo Vivi]

On Wed, Nov 01, 2017 at 04:21:08PM +, Ben Widawsky wrote:
> On 17-11-01 18:09:47, Joonas Lahtinen wrote:
> > + Kimmo and Paul
> > 
> > On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote:
> > > On 17-11-01 14:07:28, Joonas Lahtinen wrote:
> > > > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote:
> > > > > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote:
> > > > > > On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo Spurio 
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 26/10/17 03:32, Chris Wilson wrote:
> > > > > > > > It has been many years since the last confirmed sighting (and 
> > > > > > > > fix) of an
> > > > > > > > RC6 related bug (usually a system hang). Remove the parameter 
> > > > > > > > to stop
> > > > > > > > users from setting dangerous values, as they often set it 
> > > > > > > > during triage
> > > > > > > > and end up disabling the entire runtime pm instead (the option 
> > > > > > > > is not a
> > > > > > > > fine scalpel!).
> > > > > > > >
> > > > > > > > Furthermore, it allows users to set known dangerous values 
> > > > > > > > which were
> > > > > > > > intended for testing and not for production use. For testing, 
> > > > > > > > we can
> > > > > > > > always patch in the required setting without having to expose 
> > > > > > > > ourselves
> > > > > > > > to random abuse.
> > > > > > > >
> > > > > > > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and 
> > > > > > > > document the
> > > > > > > > lack of ilk support better.
> > > > > > > > v3: Clear intel_info->rc6p if we don't support rc6 itself.
> > > > > > > >
> > > > > > > > Signed-off-by: Chris Wilson 
> > > > > > > > Cc: Rodrigo Vivi 
> > > > > > > > Cc: Joonas Lahtinen 
> > > > > > > > Cc: Jani Nikula 
> > > > > > > > Cc: Imre Deak 
> > > > > > > > Cc: Daniel Vetter 
> > > > > > > > Acked-by: Daniel Vetter 
> > > > > > > > ---
> > > > > > >
> > > > > > > I think that for execution/debug on early silicon we might still 
> > > > > > > want the
> > > > > > > ability to turn features like RC6 off. Maybe we can add a debug 
> > > > > > > kconfig to
> > > > > > > force info->has_rc6 = 0? Not a blocker to this patch but worth 
> > > > > > > considering
> > > > > > > IMO.
> > > > > >
> > > > > > Most of the BIOSes I've seen on our RVPs have had an option to 
> > > > > > disable
> > > > > > RC6.
> > > > >
> > > > > BIOS option don't block our code to run and set some MMIOs.
> > > > > Not sure how the GPU will behave on such cases.
> > > > >
> > > > > I like the idea of removing some and keeping the parameters clean.
> > > > > But there are few ones like RC6 and disable_power_wells that are very
> > > > > useful on platform enabling and also when assisting others to debug 
> > > > > issues.
> > > > >
> > > > > For instance right now that we fixed RC6 on CNL someone told that
> > > > > he believe seeing more hangs, so I immediately asked to boot with
> > > > > i915.enable_rc6=0 to double check. It is easier and straighforward
> > > > > to direct them to the unsafe param than to ask them to compile the 
> > > > > code
> > > > > with different options or to use some BIOS options that we are not 
> > > > > sure.
> > > > >
> > > > > Also on bug triage some options like this are helpful.
> > > > >
> > > > > Also BIOS and compile are saved flags. So if you need to do a quick 
> > > > > test
> > > > > you have to save it, and then unsave later. Parameters are very 
> > > > > convinient
> > > > > for 1 boot only check.
> > > >
> > > > It's convenient for sure, but the unsafe module parameters seems to be
> > > > finding their way into way too many HOWTOs, and from there to some
> > > > "productized" use-cases. Chris states that setting .enable_rc6=0 to
> > > > solving an issue on publicly shipping products has been some years ago,
> > > > so I don't see a need for carrying this.
> > > >
> > > > We shouldn't allow the convenience of not having to change one line and
> > > > recompile kernel during development to affect the end-users who are
> > > > Googling how to get the best performance out of their hardware (I could
> > > > mention some distro here).
> > > >
> > > > This seems the like the best option as I don't think introducing kernel
> > > > parameters that only exists on debug builds would be too convenient
> > > > either. It'd maybe just add more confusion.
> > > >
> > > > Regards, Joonas
> > > 
> > > I believe the ability to disable RC6 is valuable not just for debugging
> > > purposes. Folks with very latency sensitive workloads are often willing to
> > > forego power savings. The real problem I see is that we don't test 
> > > without rc6
> > > in our setup, which indeed makes it unsafe. As such, I see the other 
> > > option here
> > > going back to the ability to toggle rc6 after load (either module 

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
> Op 01-11-17 om 16:29 schreef Ville Syrjälä:
> > On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
> >> This introduces a slight behavioral change to rmfb. Instead of
> >> disabling a crtc when the primary plane is disabled, we try to
> >> preserve it.
> >>
> >> Apart from old versions of the vmwgfx xorg driver, there is
> >> nothing depending on rmfb disabling a crtc.
> >>
> >> Vmwgfx' and simple kms helper atomic implementation rejects CRTC
> >> enabled without plane, so we can do this safely.

The code for those seems a bit inconsistent. The crtc check requires
that the crtc state and plane state match. But the plane check allows
the plane to be enabled w/o the crtc being enabled. I guess it doesn't
matter really since you can't enable the plane without a crtc, and the
crtc check would then catch the case where the crtc would be disabled.

Oh and looks like drm_plane_helper_check_state() is a bit buggy. It
still uses crtc->enabled instead of crtc_state->enable to check the
state of the crtc. I guess to keep drm_plane_helper_check_update()
working we may have to pass in the crtc state manually.

The vmwgfx plane check looks a bit bogus in other ways too. I guess
I'll have to fire off a couple of patches.

> >>
> >> If the atomic commit is rejected by the driver then we will still
> >> fall back to the old behavior and turn off the crtc.
> >>
> >> Changes since v1:
> >> - Restart completely when rmfb with crtc on fails (Sean Paul).
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> Cc: Sean Paul 
> >> Cc: Daniel Vetter 
> >> ---
> >>  drivers/gpu/drm/drm_framebuffer.c | 23 +--
> >>  1 file changed, 17 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> >> b/drivers/gpu/drm/drm_framebuffer.c
> >> index 2affe53f3fda..f0679468f421 100644
> >> --- a/drivers/gpu/drm/drm_framebuffer.c
> >> +++ b/drivers/gpu/drm/drm_framebuffer.c
> >> @@ -765,14 +765,18 @@ static int atomic_remove_fb(struct drm_framebuffer 
> >> *fb)
> >>struct drm_plane *plane;
> >>struct drm_connector *conn;
> >>struct drm_connector_state *conn_state;
> >> -  int i, ret = 0;
> >> +  int i, ret;
> >>unsigned plane_mask;
> >> +  bool disable_crtcs = false;
> >>  
> >> -  state = drm_atomic_state_alloc(dev);
> >> -  if (!state)
> >> -  return -ENOMEM;
> >> -
> >> +retry_disable:
> >>drm_modeset_acquire_init(, 0);
> >> +
> >> +  state = drm_atomic_state_alloc(dev);
> >> +  if (!state) {
> >> +  ret = -ENOMEM;
> >> +  goto out;
> >> +  }
> >>state->acquire_ctx = 
> >>  
> >>  retry:
> >> @@ -793,7 +797,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
> >>goto unlock;
> >>}
> >>  
> >> -  if (plane_state->crtc->primary == plane) {
> >> +  if (disable_crtcs && plane_state->crtc->primary == plane) {
> >>struct drm_crtc_state *crtc_state;
> >>  
> >>crtc_state = drm_atomic_get_existing_crtc_state(state, 
> >> plane_state->crtc);
> >> @@ -818,6 +822,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
> >>plane->old_fb = plane->fb;
> >>}
> >>  
> >> +  /* This list is only filled when disable_crtcs is set. */
> >>for_each_new_connector_in_state(state, conn, conn_state, i) {
> > WARN_ON(!disable_crtcs) maybe?
> Would be overkill, nothing before it adds connector state, and if atomic 
> check does then that's fine, but it won't be run here. :)

It would serve as a way to document that fact, even without the comment.
But I won't insist on it.

> >>ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
> >>  
> >> @@ -840,9 +845,15 @@ static int atomic_remove_fb(struct drm_framebuffer 
> >> *fb)
> >>  
> >>drm_atomic_state_put(state);
> >>  
> >> +out:
> >>drm_modeset_drop_locks();
> >>drm_modeset_acquire_fini();
> >>  
> >> +  if (ret == -EINVAL && !disable_crtcs) {
> > Hmm. -EINVAL seems rather specific. Not sure if we could just check for
> > any error?
> >
> > Or... I'm not sure if we have any central place where we do the
> > "can I disable the primary plane w/o disabling the crtc?" check. If we
> > do then we could also add a comment there informing people that the
> > -EINVAL is important.
> We don't have a central place, I check for EINVAL since that is the generic 
> atomic_check() failed error. If it fails for any other reason then we don't 
> have to retry, but pass it along. :)

Oh well. I guess people just have to be careful with their error
values. I suppoe anyone depending on the retry will notice this
issue rather quickly.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Sign commits in addition to tags

[Eric Anholt]

Sean Paul  writes:

> On Wed, Nov 1, 2017 at 7:12 AM, Gustavo Padovan  wrote:
>> 2017-10-31 Sean Paul :
>>
>>> On Tue, Oct 31, 2017 at 1:31 PM, Daniel Vetter  wrote:
>>> > On Tue, Oct 31, 2017 at 5:14 PM, Sean Paul  wrote:
>>> >> On Tue, Oct 31, 2017 at 4:27 AM, Jani Nikula
>>> >>  wrote:
>>> >>>
>>> >>> Reminder, we have this new list dim-to...@lists.freedesktop.org for
>>> >>> maintainer tools patches. Cc'd.
>>> >>>
>>> >>
>>> >> Ahh, cool. I didn't realize dim grew up!
>>> >>
>>> >>> On Mon, 30 Oct 2017, Sean Paul  wrote:
>>>  Expanding on Jani's work to sign tags, this patch adds signing for git
>>>  commit/am.
>>> >>>
>>> >>> I guess I'd like more rationale here. Is this something we should be
>>> >>> doing? Is anyone else doing this?
>>> >>>
>>> >>
>>> >> Sure thing. Signing commits allows Dave to use --verify-signatures
>>> >> when pulling. If something is not signed, we'll know it was either not
>>> >> applied with dim, or was altered on fdo (both warrant investigation).
>>> >>
>>> >> I suspect no one else is doing this since most trees are single
>>> >> maintainer, and it's not possible to sign commits via git send-email.
>>> >> Since we have the committer model, and a bunch of people with access
>>> >> to fdo and the tree, I think it's important to add this. Especially
>>> >> since we can do it in dim without overhead.
>>> >>
>>>  Signed-off-by: Sean Paul 
>>>  ---
>>> 
>>>  This has been lightly tested with dim apply-branch/dim push-branch.
>>> 
>>>  Sean
>>> 
>>>   dim | 78 
>>>  +
>>>   1 file changed, 51 insertions(+), 27 deletions(-)
>>> 
>>>  diff --git a/dim b/dim
>>>  index 527989aff9ad..cd5e41f89a3a 100755
>>>  --- a/dim
>>>  +++ b/dim
>>>  @@ -67,9 +67,6 @@ 
>>>  DIM_TEMPLATE_SIGNATURE=${DIM_TEMPLATE_SIGNATURE:-$HOME/.dim.template.signature}
>>>   # dim pull-request tag summary template
>>>   
>>>  DIM_TEMPLATE_TAG_SUMMARY=${DIM_TEMPLATE_TAG_SUMMARY:-$HOME/.dim.template.tagsummary}
>>> 
>>>  -# GPG key id for signing tags. If unset, don't sign.
>>>  -DIM_GPG_KEYID=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
>>>  -
>>>   #
>>>   # Internal configuration.
>>>   #
>>>  @@ -104,6 +101,20 @@ test_request_recipients=(
>>>   # integration configuration
>>>   integration_config=nightly.conf
>>> 
>>>  +# GPG key id for signing tags. If unset, don't sign.
>>>  +function gpg_keyid_for_tag
>>>  +{
>>>  + echo "${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}"
>>>  + return 0
>>>  +}
>>>  +
>>>  +# GPG key id for committing (git commit/am). If unset, don't sign.
>>>  +function gpg_keyid_for_commit
>>>  +{
>>>  + echo "${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}"
>>>  + return 0
>>>  +}
>>> >>>
>>> >>> This seems like an overly complicated way to achieve what you want.
>>> >>>
>>> >>> Just put these under "Internal configuration." instead:
>>> >>>
>>> >>> dim_gpg_sign_tag=${DIM_GPG_KEYID:+-u $DIM_GPG_KEYID}
>>> >>> dim_gpg_sign_commit=${DIM_GPG_KEYID:+-S$DIM_GPG_KEYID}
>>> >>>
>>> >>> And use directly in git tag and commit, respectively?
>>> >>>
>>> >>
>>> >> Yep, sounds good.
>>> >>
>>> >>> Although... perhaps starting to sign tags should not force signing
>>> >>> commits?
>>> >>>
>>> >>
>>> >> Why would it be desirable to *not* sign tags?
>>> >
>>> > Again, what's the threat model you're trying to defend against? Atm
>>> > anyone with commit rights to fd.o can push whatever they want to. If
>>> > they want to be evil, they can also push whatever kind of garbage they
>>> > want to, including commit signature and and fake Link: and review
>>> > tags. With pull requests/tags signing them prevents a
>>> > man-in-the-midddle attack of the unprotected pull request in the mail,
>>> > but I still don't see what signing commits protects against.
>>>
>>> This is protecting against a bad actor (either through a committer's
>>> account, or some other fdo account) gaining access to the tree on fdo
>>> and either adding a malicious commit, or altering an existing commit.
>>
>> Yeah, but then we need to enforce it for all committer
>
> My hope is that dim makes it easy enough to get everyone on board
> eventually. In the interim, the people with signing commits will be
> able to attest that those commits were applied by them.
>
>> and we also need
>> a signing party to sign each others keys.
>
> I feel like most of us see each other often enough to make this
> possible. Even without a signing party, we still get *some* amount of
> coverage by virtue of TOFU [1].
>
> Is anyone against the idea of signing commits? Is there a reason that
> we shouldn't?

We've used GPG a bunch in fdo infrastructure, and 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/drm_vma_manager.c: Remove useless goto statement

[Patchwork]

== Series Details ==

Series: drm/drm_vma_manager.c: Remove useless goto statement
URL   : https://patchwork.freedesktop.org/series/32987/
State : success

== Summary ==

Series 32987v1 drm/drm_vma_manager.c: Remove useless goto statement
https://patchwork.freedesktop.org/api/1.0/series/32987/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-glk-dsi)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:447s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:510s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:494s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:569s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:258s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:586s
fi-glk-dsi   total:289  pass:257  dwarn:0   dfail:0   fail:2   skip:30  
time:491s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:438s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:572s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:571s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:598s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:649s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:572s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:420s

fff06da054b4752eabf7d4103d30a281f8de96d9 drm-tip: 2017y-11m-01d-13h-47m-20s UTC 
integration manifest
c78001f8a807 drm/drm_vma_manager.c: Remove useless goto statement

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6296/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/drivers: drop redundant drm_edid_to_eld() calls

[Eric Anholt]

Jani Nikula  writes:

> drm_add_edid_modes() now fills in the ELD automatically, so the calls to
> drm_edid_to_eld() are redundant. Remove them.
>
> All the other places are obvious, but nv50 has detached
> drm_edid_to_eld() from the drm_add_edid_modes() call.

Nice!  For vc4,

Acked-by: Eric Anholt 


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Runtime disable for eDP DRRS

[C, Ramalingam]

> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, November 1, 2017 12:27 AM
> To: C, Ramalingam 
> Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R
> ; ch...@chris-wilson.co.uk
> Subject: Re: [PATCH 1/2] drm/i915: Runtime disable for eDP DRRS
> 
> On Tue, Oct 31, 2017 at 09:20:42AM +, Ramalingam C wrote:
> > From: "C, Ramalingam" 
> >
> > Module parameter enable_drrs(Boolean flag) is added to control the
> > eDP Idleness drrs enable flow.
> 
> This goes on the opposite direction of the current trends.
> 
> Well, I'm a big fan of the parameters, but there's a big effort
> going on to remove all kernel parameters. I believe it will
> be just a matter of time that we have to remove fbc and psr as well.
> So probably not a good idea to add something now that we will
> have to rework soon.
> 
> Maybe we could add a on/off toggle on DRRS now and then
> when we remove the parameter for fbc and psr we also add toggles
> on debugfs...

Based on our offline discussion, I will use the debugfs to toggle the DRRS 
instead of modparams.
Once the code is ready I will share it for the review.

Thanks
--Ram
> 
> Thanks,
> Rodrigo.
> 
> >
> > Modification to this module parameter will be considered on next
> > eDP_DRRS enable flow. So after module parameter update, a modeset
> > will help to modify the feature state as per the module parameter's
> > current state.
> >
> > Possibility of disabling the DRRS, enables the testing of the
> > frontbuffer tracking based features (FBC, DRRS and PSR) as standalone
> > or any combination of the set.
> >
> > Signed-off-by: C, Ramalingam 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c | 3 +++
> >  drivers/gpu/drm/i915/i915_params.h | 3 ++-
> >  drivers/gpu/drm/i915/intel_dp.c| 6 ++
> >  3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> > index b4faeb6aa2bd..32f06bb74f9d 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -190,3 +190,6 @@ i915_param_named(enable_dpcd_backlight, bool,
> 0600,
> >
> >  i915_param_named(enable_gvt, bool, 0400,
> > "Enable support for Intel GVT-g graphics virtualization host
> support(default:false)");
> > +
> > +i915_param_named_unsafe(enable_drrs, bool, 0600,
> > +   "Enable DRRS. (True=Enabled, False=Disabled [Default])");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> > index c7292268ed43..3c6fdce1c122 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -67,7 +67,8 @@
> > param(bool, nuclear_pageflip, false) \
> > param(bool, enable_dp_mst, true) \
> > param(bool, enable_dpcd_backlight, false) \
> > -   param(bool, enable_gvt, false)
> > +   param(bool, enable_gvt, false) \
> > +   param(bool, enable_drrs, false)
> >
> >  #define MEMBER(T, member, ...) T member;
> >  struct i915_params {
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index ca48bce23a6f..ff9964cf15cd 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5568,6 +5568,11 @@ void intel_edp_drrs_enable(struct intel_dp
> *intel_dp,
> > return;
> > }
> >
> > +   if (!i915_modparams.enable_drrs) {
> > +   DRM_DEBUG_KMS("DRRS is disabled from modparams\n");
> > +   return;
> > +   }
> > +
> > mutex_lock(_priv->drrs.mutex);
> > if (WARN_ON(dev_priv->drrs.dp)) {
> > DRM_ERROR("DRRS already enabled\n");
> > @@ -5817,6 +5822,7 @@ intel_dp_drrs_init(struct intel_connector
> *intel_connector,
> > }
> >
> > dev_priv->drrs.type = dev_priv->vbt.drrs_type;
> > +   i915_modparams.enable_drrs = true;
> >
> > dev_priv->drrs.refresh_rate_type = DRRS_HIGH_RR;
> > DRM_DEBUG_KMS("seamless DRRS supported for eDP panel.\n");
> > --
> > 2.7.4
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Implement ReadHitWriteOnlyDisable.

[Rafael Antognolli]

The workaround for this is described as:

"if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if
RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1"

So it looks like the userspace should be responsible for setting these,
based on the number of multisamples dependency. However, the register
that controls RCC clock gating is not a context register, and cannot be
set by userspace.

Since we would end up setting one or another based on the number of
multisamples anyway, it seems harmless to just set both all the time.

This change (specially the GEN10_READ_HIT_WRITEONLY_DISABLE bit)
improves CNL stability by avoiding some of the hangs seen in the
platform.

Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8c775e96b4e4..d9a65cebefaa 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3837,6 +3837,7 @@ enum {
  */
 #define SLICE_UNIT_LEVEL_CLKGATE   _MMIO(0x94d4)
 #define  SARBUNIT_CLKGATE_DIS  (1 << 5)
+#define  RCCUNIT_CLKGATE_DIS   (1 << 7)
 
 /*
  * Display engine regs
@@ -7016,6 +7017,7 @@ enum {
 #define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
 # define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
 # define GEN9_RHWO_OPTIMIZATION_DISABLE(1<<14)
+# define GEN10_READ_HIT_WRITEONLY_DISABLE  (1<<14)
 #define COMMON_SLICE_CHICKEN2  _MMIO(0x7014)
 # define GEN9_PBE_COMPRESSED_HASH_SELECTION(1<<13)
 # define GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE (1<<12)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index f31f2d6384c3..0d8e25a4623a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1320,6 +1320,11 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1, GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
 
+   /* ReadHitWriteOnlyDisable: cnl */
+   WA_SET_BIT_MASKED(GEN7_COMMON_SLICE_CHICKEN1,
+ GEN10_READ_HIT_WRITEONLY_DISABLE);
+   WA_SET_BIT_MASKED(SLICE_UNIT_LEVEL_CLKGATE, RCCUNIT_CLKGATE_DIS);
+
/* WaEnablePreemptionGranularityControlByUMD:cnl */
I915_WRITE(GEN7_FF_SLICE_CS_CHICKEN1,
   _MASKED_BIT_ENABLE(GEN9_FFSC_PERCTX_PREEMPT_CTRL));
-- 
2.13.6

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Patchwork]

== Series Details ==

Series: drm/atomic: Try to preserve the crtc enabled state in 
drm_atomic_remove_fb, v2.
URL   : https://patchwork.freedesktop.org/series/32985/
State : warning

== Summary ==

Series 32985v1 drm/atomic: Try to preserve the crtc enabled state in 
drm_atomic_remove_fb, v2.
https://patchwork.freedesktop.org/api/1.0/series/32985/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-glk-dsi)
Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-many-each:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-store-each:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-blb-e6850)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-await-all:
pass   -> SKIP   (fi-blb-e6850)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-blb-e6850)
Subgroup basic-flip-b:
pass   -> SKIP   (fi-blb-e6850)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> SKIP   (fi-blb-e6850)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#101705 +1

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-blb-e6850 total:289  pass:210  dwarn:1   dfail:0   fail:0   skip:78  
time:357s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:274s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:486s
fi-cfl-s total:289  pass:251  dwarn:5   dfail:0   fail:0   skip:33  
time:523s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:492s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:426s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:523s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:569s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:558s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:422s

fff06da054b4752eabf7d4103d30a281f8de96d9 drm-tip: 2017y-11m-01d-13h-47m-20s UTC 
integration manifest
bc724f51d670 drm/atomic: Try to preserve the crtc enabled state in 
drm_atomic_remove_fb, v2.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6295/
___
Intel-gfx mailing 

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

[Ben Widawsky]

On 17-11-01 18:09:47, Joonas Lahtinen wrote:

+ Kimmo and Paul

On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote:

On 17-11-01 14:07:28, Joonas Lahtinen wrote:
> On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote:
> > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote:
> > > On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo Spurio wrote:
> > > >
> > > >
> > > > On 26/10/17 03:32, Chris Wilson wrote:
> > > > > It has been many years since the last confirmed sighting (and fix) of 
an
> > > > > RC6 related bug (usually a system hang). Remove the parameter to stop
> > > > > users from setting dangerous values, as they often set it during 
triage
> > > > > and end up disabling the entire runtime pm instead (the option is not 
a
> > > > > fine scalpel!).
> > > > >
> > > > > Furthermore, it allows users to set known dangerous values which were
> > > > > intended for testing and not for production use. For testing, we can
> > > > > always patch in the required setting without having to expose 
ourselves
> > > > > to random abuse.
> > > > >
> > > > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the
> > > > > lack of ilk support better.
> > > > > v3: Clear intel_info->rc6p if we don't support rc6 itself.
> > > > >
> > > > > Signed-off-by: Chris Wilson 
> > > > > Cc: Rodrigo Vivi 
> > > > > Cc: Joonas Lahtinen 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Imre Deak 
> > > > > Cc: Daniel Vetter 
> > > > > Acked-by: Daniel Vetter 
> > > > > ---
> > > >
> > > > I think that for execution/debug on early silicon we might still want 
the
> > > > ability to turn features like RC6 off. Maybe we can add a debug kconfig 
to
> > > > force info->has_rc6 = 0? Not a blocker to this patch but worth 
considering
> > > > IMO.
> > >
> > > Most of the BIOSes I've seen on our RVPs have had an option to disable
> > > RC6.
> >
> > BIOS option don't block our code to run and set some MMIOs.
> > Not sure how the GPU will behave on such cases.
> >
> > I like the idea of removing some and keeping the parameters clean.
> > But there are few ones like RC6 and disable_power_wells that are very
> > useful on platform enabling and also when assisting others to debug issues.
> >
> > For instance right now that we fixed RC6 on CNL someone told that
> > he believe seeing more hangs, so I immediately asked to boot with
> > i915.enable_rc6=0 to double check. It is easier and straighforward
> > to direct them to the unsafe param than to ask them to compile the code
> > with different options or to use some BIOS options that we are not sure.
> >
> > Also on bug triage some options like this are helpful.
> >
> > Also BIOS and compile are saved flags. So if you need to do a quick test
> > you have to save it, and then unsave later. Parameters are very convinient
> > for 1 boot only check.
>
> It's convenient for sure, but the unsafe module parameters seems to be
> finding their way into way too many HOWTOs, and from there to some
> "productized" use-cases. Chris states that setting .enable_rc6=0 to
> solving an issue on publicly shipping products has been some years ago,
> so I don't see a need for carrying this.
>
> We shouldn't allow the convenience of not having to change one line and
> recompile kernel during development to affect the end-users who are
> Googling how to get the best performance out of their hardware (I could
> mention some distro here).
>
> This seems the like the best option as I don't think introducing kernel
> parameters that only exists on debug builds would be too convenient
> either. It'd maybe just add more confusion.
>
> Regards, Joonas

I believe the ability to disable RC6 is valuable not just for debugging
purposes. Folks with very latency sensitive workloads are often willing to
forego power savings. The real problem I see is that we don't test without rc6
in our setup, which indeed makes it unsafe. As such, I see the other option here
going back to the ability to toggle rc6 after load (either module parameter, or
make it sysfs), and actually run some subset of our workloads with RC6. I
suspect people will poop on that suggestion, but I figured I'd mention.


I agree there, but by my understanding there's really no ask to support
the feature in upstream. And the original motive from Chris to drop the
feature is that it's unsafe as it currently is.

So unless we've got the resources to bring it back from the unsafe
zone, I think we should drop it like this patch proposes.

Regards, Joonas


Yep, I agree. One other option would be to move i915_forcewake_user to sysfs and
let them use that.

--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

[Joonas Lahtinen]

+ Kimmo and Paul

On Wed, 2017-11-01 at 07:43 -0700, Ben Widawsky wrote:
> On 17-11-01 14:07:28, Joonas Lahtinen wrote:
> > On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote:
> > > On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote:
> > > > On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo Spurio wrote:
> > > > > 
> > > > > 
> > > > > On 26/10/17 03:32, Chris Wilson wrote:
> > > > > > It has been many years since the last confirmed sighting (and fix) 
> > > > > > of an
> > > > > > RC6 related bug (usually a system hang). Remove the parameter to 
> > > > > > stop
> > > > > > users from setting dangerous values, as they often set it during 
> > > > > > triage
> > > > > > and end up disabling the entire runtime pm instead (the option is 
> > > > > > not a
> > > > > > fine scalpel!).
> > > > > > 
> > > > > > Furthermore, it allows users to set known dangerous values which 
> > > > > > were
> > > > > > intended for testing and not for production use. For testing, we can
> > > > > > always patch in the required setting without having to expose 
> > > > > > ourselves
> > > > > > to random abuse.
> > > > > > 
> > > > > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document 
> > > > > > the
> > > > > > lack of ilk support better.
> > > > > > v3: Clear intel_info->rc6p if we don't support rc6 itself.
> > > > > > 
> > > > > > Signed-off-by: Chris Wilson 
> > > > > > Cc: Rodrigo Vivi 
> > > > > > Cc: Joonas Lahtinen 
> > > > > > Cc: Jani Nikula 
> > > > > > Cc: Imre Deak 
> > > > > > Cc: Daniel Vetter 
> > > > > > Acked-by: Daniel Vetter 
> > > > > > ---
> > > > > 
> > > > > I think that for execution/debug on early silicon we might still want 
> > > > > the
> > > > > ability to turn features like RC6 off. Maybe we can add a debug 
> > > > > kconfig to
> > > > > force info->has_rc6 = 0? Not a blocker to this patch but worth 
> > > > > considering
> > > > > IMO.
> > > > 
> > > > Most of the BIOSes I've seen on our RVPs have had an option to disable
> > > > RC6.
> > > 
> > > BIOS option don't block our code to run and set some MMIOs.
> > > Not sure how the GPU will behave on such cases.
> > > 
> > > I like the idea of removing some and keeping the parameters clean.
> > > But there are few ones like RC6 and disable_power_wells that are very
> > > useful on platform enabling and also when assisting others to debug 
> > > issues.
> > > 
> > > For instance right now that we fixed RC6 on CNL someone told that
> > > he believe seeing more hangs, so I immediately asked to boot with
> > > i915.enable_rc6=0 to double check. It is easier and straighforward
> > > to direct them to the unsafe param than to ask them to compile the code
> > > with different options or to use some BIOS options that we are not sure.
> > > 
> > > Also on bug triage some options like this are helpful.
> > > 
> > > Also BIOS and compile are saved flags. So if you need to do a quick test
> > > you have to save it, and then unsave later. Parameters are very convinient
> > > for 1 boot only check.
> > 
> > It's convenient for sure, but the unsafe module parameters seems to be
> > finding their way into way too many HOWTOs, and from there to some
> > "productized" use-cases. Chris states that setting .enable_rc6=0 to
> > solving an issue on publicly shipping products has been some years ago,
> > so I don't see a need for carrying this.
> > 
> > We shouldn't allow the convenience of not having to change one line and
> > recompile kernel during development to affect the end-users who are
> > Googling how to get the best performance out of their hardware (I could
> > mention some distro here).
> > 
> > This seems the like the best option as I don't think introducing kernel
> > parameters that only exists on debug builds would be too convenient
> > either. It'd maybe just add more confusion.
> > 
> > Regards, Joonas
> 
> I believe the ability to disable RC6 is valuable not just for debugging
> purposes. Folks with very latency sensitive workloads are often willing to
> forego power savings. The real problem I see is that we don't test without rc6
> in our setup, which indeed makes it unsafe. As such, I see the other option 
> here
> going back to the ability to toggle rc6 after load (either module parameter, 
> or
> make it sysfs), and actually run some subset of our workloads with RC6. I
> suspect people will poop on that suggestion, but I figured I'd mention.

I agree there, but by my understanding there's really no ask to support
the feature in upstream. And the original motive from Chris to drop the
feature is that it's unsafe as it currently is.

So unless we've got the resources to bring it back from the unsafe
zone, I think we should drop it like this patch proposes.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Re-enable fastboot by default

[Patchwork]

== Series Details ==

Series: drm/i915: Re-enable fastboot by default
URL   : https://patchwork.freedesktop.org/series/32984/
State : failure

== Summary ==

Series 32984v1 drm/i915: Re-enable fastboot by default
https://patchwork.freedesktop.org/api/1.0/series/32984/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test debugfs_test:
Subgroup read_all_entries:
pass   -> FAIL   (fi-hsw-4770)
pass   -> FAIL   (fi-bdw-5557u)
Test gem_ctx_switch:
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-glk-dsi)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-WARN (fi-bdw-5557u) fdo#102473
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-glk-1)

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102473 https://bugs.freedesktop.org/show_bug.cgi?id=102473

fi-bdw-5557u total:289  pass:266  dwarn:1   dfail:0   fail:1   skip:21  
time:444s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:508s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:490s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:552s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:262s
fi-glk-1 total:289  pass:260  dwarn:1   dfail:0   fail:0   skip:28  
time:589s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:494s
fi-hsw-4770  total:289  pass:261  dwarn:0   dfail:0   fail:1   skip:27  
time:432s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:484s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:574s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:587s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:578s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:591s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:646s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:528s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:570s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:420s

fff06da054b4752eabf7d4103d30a281f8de96d9 drm-tip: 2017y-11m-01d-13h-47m-20s UTC 
integration manifest
337f7fdfce73 drm/i915: Re-enable fastboot by default

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6294/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] Test case for drm_vblank_cleanup refcount validation patch

[PrasannaKumar Muralidharan]

Hi Daniel,

On 1 November 2017 at 14:23, Daniel Vetter  wrote:
> On Wed, Nov 01, 2017 at 09:48:28AM +0530, PrasannaKumar Muralidharan wrote:
>> Hi Daniel,
>>
>> On 31 October 2017 at 21:57, Daniel Vetter  wrote:
>> > On Tue, Oct 31, 2017 at 08:37:21PM +0530, PrasannaKumar Muralidharan wrote:
>> >> My patch is supposed to catch problem with drivers. It warns when
>> >> vblank refcount is non-zero in drm_vblank_cleanup call. From CI log it
>> >> can be seen that warning being triggered. I feel that my patch is
>> >> exposing existing issue.
>> >>
>> >> If I misinterpreted something please let me know.
>> >
>> > This is probably what's happening, but I can't merge a patch that breaks
>> > CI. So we need to track down that issue before merging.
>>
>> I understand. Being new to DRM subsystem I don't know if I can
>> contribute in finding the issue. I would be able to help if I could
>> get some guidance.
>
> If you have an intel laptop anywhere at hand that you could use to
> reproduce the issue, that would be a good start.

I do have one but it is my primary machine.

> Then go through the setup for the kms/drm validation suite:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-and-validation
>
> That should allow you to locally reproduce the issue (it seems to affect
> many machines, so I'd assume it doesn't matter which one you have).

If this setup is going to affect my normal workflow setup I would
prefer not to use it.

> Once you can reproduce it should be doable to figure out where we leak
> this reference (but usually it's a bit of hard work).

Anyway I will give it a try and see how far I can go.

> Btw I discussed your patch a bit on irc, a first step would be to also
> print the refcount when it's leaked, not just warn about it. Knowing how
> many references are leaked is sometimes a good hint about what's going on.

I will send a v4.

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Regards,
PrasannaKumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Maarten Lankhorst]

Op 01-11-17 om 16:29 schreef Ville Syrjälä:
> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
>> This introduces a slight behavioral change to rmfb. Instead of
>> disabling a crtc when the primary plane is disabled, we try to
>> preserve it.
>>
>> Apart from old versions of the vmwgfx xorg driver, there is
>> nothing depending on rmfb disabling a crtc.
>>
>> Vmwgfx' and simple kms helper atomic implementation rejects CRTC
>> enabled without plane, so we can do this safely.
>>
>> If the atomic commit is rejected by the driver then we will still
>> fall back to the old behavior and turn off the crtc.
>>
>> Changes since v1:
>> - Restart completely when rmfb with crtc on fails (Sean Paul).
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Sean Paul 
>> Cc: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/drm_framebuffer.c | 23 +--
>>  1 file changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> b/drivers/gpu/drm/drm_framebuffer.c
>> index 2affe53f3fda..f0679468f421 100644
>> --- a/drivers/gpu/drm/drm_framebuffer.c
>> +++ b/drivers/gpu/drm/drm_framebuffer.c
>> @@ -765,14 +765,18 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>>  struct drm_plane *plane;
>>  struct drm_connector *conn;
>>  struct drm_connector_state *conn_state;
>> -int i, ret = 0;
>> +int i, ret;
>>  unsigned plane_mask;
>> +bool disable_crtcs = false;
>>  
>> -state = drm_atomic_state_alloc(dev);
>> -if (!state)
>> -return -ENOMEM;
>> -
>> +retry_disable:
>>  drm_modeset_acquire_init(, 0);
>> +
>> +state = drm_atomic_state_alloc(dev);
>> +if (!state) {
>> +ret = -ENOMEM;
>> +goto out;
>> +}
>>  state->acquire_ctx = 
>>  
>>  retry:
>> @@ -793,7 +797,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>>  goto unlock;
>>  }
>>  
>> -if (plane_state->crtc->primary == plane) {
>> +if (disable_crtcs && plane_state->crtc->primary == plane) {
>>  struct drm_crtc_state *crtc_state;
>>  
>>  crtc_state = drm_atomic_get_existing_crtc_state(state, 
>> plane_state->crtc);
>> @@ -818,6 +822,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>>  plane->old_fb = plane->fb;
>>  }
>>  
>> +/* This list is only filled when disable_crtcs is set. */
>>  for_each_new_connector_in_state(state, conn, conn_state, i) {
> WARN_ON(!disable_crtcs) maybe?
Would be overkill, nothing before it adds connector state, and if atomic check 
does then that's fine, but it won't be run here. :)
>>  ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
>>  
>> @@ -840,9 +845,15 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>>  
>>  drm_atomic_state_put(state);
>>  
>> +out:
>>  drm_modeset_drop_locks();
>>  drm_modeset_acquire_fini();
>>  
>> +if (ret == -EINVAL && !disable_crtcs) {
> Hmm. -EINVAL seems rather specific. Not sure if we could just check for
> any error?
>
> Or... I'm not sure if we have any central place where we do the
> "can I disable the primary plane w/o disabling the crtc?" check. If we
> do then we could also add a comment there informing people that the
> -EINVAL is important.
We don't have a central place, I check for EINVAL since that is the generic 
atomic_check() failed error. If it fails for any other reason then we don't 
have to retry, but pass it along. :)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [drm-intel:for-linux-next 3/4] drivers/gpu/drm/i915/intel_engine_cs.c:1620:30: error: 'dev_priv' undeclared

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   3265124a2d3744d789ede58452ab6f8a9b454be8
commit: 680273879d125d644831b8de42c66576e6290378 [3/4] drm/i915: Move 
parking-while-active warning to intel_engines_park()
config: i386-randconfig-x003-201744 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 680273879d125d644831b8de42c66576e6290378
# save the attached .config to linux build tree
make ARCH=i386 

Note: the drm-intel/for-linux-next HEAD 
3265124a2d3744d789ede58452ab6f8a9b454be8 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_engine_cs.c: In function 'intel_engines_park':
>> drivers/gpu/drm/i915/intel_engine_cs.c:1620:30: error: 'dev_priv' undeclared 
>> (first use in this function)
 if (!intel_engines_are_idle(dev_priv))
 ^~~~
   drivers/gpu/drm/i915/intel_engine_cs.c:1620:30: note: each undeclared 
identifier is reported only once for each function it appears in

vim +/dev_priv +1620 drivers/gpu/drm/i915/intel_engine_cs.c

  1602  
  1603  /**
  1604   * intel_engines_park: called when the GT is transitioning from 
busy->idle
  1605   * @i915: the i915 device
  1606   *
  1607   * The GT is now idle and about to go to sleep (maybe never to wake 
again?).
  1608   * Time for us to tidy and put away our toys (release resources back to 
the
  1609   * system).
  1610   */
  1611  void intel_engines_park(struct drm_i915_private *i915)
  1612  {
  1613  struct intel_engine_cs *engine;
  1614  enum intel_engine_id id;
  1615  
  1616  /*
  1617   * We are committed now to parking the engines, make sure there
  1618   * will be no more interrupts arriving later.
  1619   */
> 1620  if (!intel_engines_are_idle(dev_priv))
  1621  DRM_ERROR("Timeout waiting for engines to idle\n");
  1622  
  1623  for_each_engine(engine, i915, id) {
  1624  if (engine->park)
  1625  engine->park(engine);
  1626  
  1627  intel_engine_disarm_breadcrumbs(engine);
  1628  tasklet_kill(>execlists.irq_tasklet);
  1629  
  1630  i915_gem_batch_pool_fini(>batch_pool);
  1631  engine->execlists.no_priolist = false;
  1632  }
  1633  }
  1634  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid and drivers: ELD refactoring

[Patchwork]

== Series Details ==

Series: drm/edid and drivers: ELD refactoring
URL   : https://patchwork.freedesktop.org/series/32979/
State : warning

== Summary ==

Series 32979v1 drm/edid and drivers: ELD refactoring
https://patchwork.freedesktop.org/api/1.0/series/32979/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-glk-dsi)
Test kms_addfb_basic:
Subgroup size-max:
pass   -> DMESG-WARN (fi-bsw-n3050)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:242  dwarn:1   dfail:0   fail:0   skip:46  
time:533s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:507s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:496s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:561s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:260s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:591s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:496s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:428s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:492s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:574s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:574s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:592s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:578s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:423s

fff06da054b4752eabf7d4103d30a281f8de96d9 drm-tip: 2017y-11m-01d-13h-47m-20s UTC 
integration manifest
d0fc47b51594 drm/edid: make drm_edid_to_eld() static
859c5e629962 drm/drivers: drop redundant drm_edid_to_eld() calls
4a7493663f50 drm/edid: build ELD in drm_add_edid_modes()
570227488170 drm/edid: abstract connector ELD clearing
6b35a9549f76 drm/i915: remove redundant ELD connector type update
05735647b7dc drm/edid: set ELD connector type in drm_edid_to_eld()
a13cd00cbf91 drm/edid: use macros for ELD offsets and values

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6293/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
> This introduces a slight behavioral change to rmfb. Instead of
> disabling a crtc when the primary plane is disabled, we try to
> preserve it.
> 
> Apart from old versions of the vmwgfx xorg driver, there is
> nothing depending on rmfb disabling a crtc.
> 
> Vmwgfx' and simple kms helper atomic implementation rejects CRTC
> enabled without plane, so we can do this safely.
> 
> If the atomic commit is rejected by the driver then we will still
> fall back to the old behavior and turn off the crtc.
> 
> Changes since v1:
> - Restart completely when rmfb with crtc on fails (Sean Paul).
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Sean Paul 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 2affe53f3fda..f0679468f421 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -765,14 +765,18 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>   struct drm_plane *plane;
>   struct drm_connector *conn;
>   struct drm_connector_state *conn_state;
> - int i, ret = 0;
> + int i, ret;
>   unsigned plane_mask;
> + bool disable_crtcs = false;
>  
> - state = drm_atomic_state_alloc(dev);
> - if (!state)
> - return -ENOMEM;
> -
> +retry_disable:
>   drm_modeset_acquire_init(, 0);
> +
> + state = drm_atomic_state_alloc(dev);
> + if (!state) {
> + ret = -ENOMEM;
> + goto out;
> + }
>   state->acquire_ctx = 
>  
>  retry:
> @@ -793,7 +797,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>   goto unlock;
>   }
>  
> - if (plane_state->crtc->primary == plane) {
> + if (disable_crtcs && plane_state->crtc->primary == plane) {
>   struct drm_crtc_state *crtc_state;
>  
>   crtc_state = drm_atomic_get_existing_crtc_state(state, 
> plane_state->crtc);
> @@ -818,6 +822,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>   plane->old_fb = plane->fb;
>   }
>  
> + /* This list is only filled when disable_crtcs is set. */
>   for_each_new_connector_in_state(state, conn, conn_state, i) {

WARN_ON(!disable_crtcs) maybe?

>   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
>  
> @@ -840,9 +845,15 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>  
>   drm_atomic_state_put(state);
>  
> +out:
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
>  
> + if (ret == -EINVAL && !disable_crtcs) {

Hmm. -EINVAL seems rather specific. Not sure if we could just check for
any error?

Or... I'm not sure if we have any central place where we do the
"can I disable the primary plane w/o disabling the crtc?" check. If we
do then we could also add a comment there informing people that the
-EINVAL is important.

> + disable_crtcs = true;
> + goto retry_disable;
> + }
> +
>   return ret;
>  }
>  
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Generalize transcoder looping

[Jani Nikula]

On Wed, 01 Nov 2017, Mika Kahola  wrote:
> To make looping through transcoders in intel_ddi.c more generic, let's switch
> to use 'for_each_pipe()' macro to do this.
>
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ace674c..3df991b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1717,7 +1717,7 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> *encoder,
>   goto out;
>   }
>  
> - for (i = TRANSCODER_A; i <= TRANSCODER_C; i++) {
> + for_each_pipe(dev_priv, i) {

It gives me an uneasy feeling to conflate pipes and transcoders like
this. I think we've tried to be more clear about the distinction
elsewhere.

BR,
Jani.

>   tmp = I915_READ(TRANS_DDI_FUNC_CTL(i));
>  
>   if ((tmp & TRANS_DDI_PORT_MASK) == TRANS_DDI_SELECT_PORT(port)) 
> {

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid and drivers: ELD refactoring

[Patchwork]

== Series Details ==

Series: drm/edid and drivers: ELD refactoring
URL   : https://patchwork.freedesktop.org/series/32979/
State : warning

== Summary ==

Series 32979v1 drm/edid and drivers: ELD refactoring
https://patchwork.freedesktop.org/api/1.0/series/32979/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test gem_ctx_switch:
Subgroup basic-default-heavy:
incomplete -> PASS   (fi-glk-dsi)
Test kms_flip:
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (fi-bsw-n3050)

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:242  dwarn:1   dfail:0   fail:0   skip:46  
time:530s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:511s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:497s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:619s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:265s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:586s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:481s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:579s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:587s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:570s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:599s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:579s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:424s

fff06da054b4752eabf7d4103d30a281f8de96d9 drm-tip: 2017y-11m-01d-13h-47m-20s UTC 
integration manifest
b204d850680d drm/edid: make drm_edid_to_eld() static
e5f4b2ef3fc6 drm/drivers: drop redundant drm_edid_to_eld() calls
422532ca5817 drm/edid: build ELD in drm_add_edid_modes()
5ae5199e5488 drm/edid: abstract connector ELD clearing
8d3e792a8d5a drm/i915: remove redundant ELD connector type update
ff05a50b7b2b drm/edid: set ELD connector type in drm_edid_to_eld()
19bd7713a43d drm/edid: use macros for ELD offsets and values

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6292/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable fastboot by default

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 05:06:43PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 01, 2017 at 03:53:25PM +0100, Maarten Lankhorst wrote:
> > This fix was originally reverted because it left a chromebook pixel
> > black, and no immediate fix was available. This has been fixed in the
> > meantime.
> > 
> > Rather than trying to remove the parameter, set it to default to true
> > for now, so we can always back out if required.
> 
> Like I said we have gaps in the state readout (eg. infoframes), so this
> doesn't look entirely sane to me.

BTW speaking of infofames I started moving them into atomic state(s),
but I didn't add full readout yet.

git://github.com/vsyrjala/linux.git infoframe_state_const

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Give more details for the active-when-parking warning for the engines

[Chris Wilson]

Quoting Mika Kuoppala (2017-10-27 14:25:09)
> Chris Wilson  writes:
> 
> > If the we think the engine is still active when we attempt to park it,
> > we want more details -- so dump the engine state.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=103479
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> 
> Acked-by: Mika Kuoppala 
> 
> You can poke me to upgrade for r-b when the drm_debug_printer
> stuff falls in place.

Oops, on re-reading saw the poke-me, I presumed you gave a conditional
r-b on getting the drm_printer pr_debug output enabled, which was done.

I hope not too great a faux pas
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/drm_vma_manager.c: Remove useless goto statement

[Liviu Dudau]

Commit db2395eccf08i ("drm: Convert drm_vma_manager to embedded
interval-tree in drm_mm") removed a line in drm_vma_offset_add() function that
makes checking the result of calling drm_mm_insert_node() and the goto
call redundant. Rework the function (as suggested by Chris Wilson) to
eliminate the need for the goto and associated label.

v2: rewrite function to remove all goto statements.

Fixes: db2395eccf08i ("drm: Convert drm_vma_manager to embedded interval-tree 
in drm_mm")
Cc: Chris Wilson 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/drm_vma_manager.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_vma_manager.c 
b/drivers/gpu/drm/drm_vma_manager.c
index 28f1226576f8c..23c749c05b5aa 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -203,21 +203,16 @@ EXPORT_SYMBOL(drm_vma_offset_lookup_locked);
 int drm_vma_offset_add(struct drm_vma_offset_manager *mgr,
   struct drm_vma_offset_node *node, unsigned long pages)
 {
-   int ret;
+   int ret = 0;
 
write_lock(>vm_lock);
 
-   if (drm_mm_node_allocated(>vm_node)) {
-   ret = 0;
-   goto out_unlock;
-   }
+   if (!drm_mm_node_allocated(>vm_node))
+   ret = drm_mm_insert_node(>vm_addr_space_mm,
+>vm_node, pages);
 
-   ret = drm_mm_insert_node(>vm_addr_space_mm, >vm_node, pages);
-   if (ret)
-   goto out_unlock;
-
-out_unlock:
write_unlock(>vm_lock);
+
return ret;
 }
 EXPORT_SYMBOL(drm_vma_offset_add);
-- 
2.14.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable fastboot by default

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 03:53:25PM +0100, Maarten Lankhorst wrote:
> This fix was originally reverted because it left a chromebook pixel
> black, and no immediate fix was available. This has been fixed in the
> meantime.
> 
> Rather than trying to remove the parameter, set it to default to true
> for now, so we can always back out if required.

Like I said we have gaps in the state readout (eg. infoframes), so this
doesn't look entirely sane to me.

> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Testcase: kms_panel_fitting
> ---
>  drivers/gpu/drm/i915/i915_params.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index e54e6a4bc6bd..396126aac932 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -57,7 +57,7 @@
>   param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \
>   param(bool, enable_cmd_parser, true) \
>   param(bool, enable_hangcheck, true) \
> - param(bool, fastboot, false) \
> + param(bool, fastboot, true) \
>   param(bool, prefault_disable, false) \
>   param(bool, load_detect_test, false) \
>   param(bool, force_reset_modeset_test, false) \
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/drivers: drop redundant drm_edid_to_eld() calls

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 04:21:02PM +0200, Jani Nikula wrote:
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index e4751f92b342..e0a190a0f029 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -2688,7 +2688,6 @@ nv50_audio_enable(struct drm_encoder *encoder, struct 
> drm_display_mode *mode)
>   if (!drm_detect_monitor_audio(nv_connector->edid))
>   return;
>  
> - drm_edid_to_eld(_connector->base, nv_connector->edid);
>   memcpy(args.data, nv_connector->base.eld, sizeof(args.data));
>  
>   nvif_mthd(disp->disp, 0, ,

This being the only call outside a .get_modes() hook means this is the
only one that might change some behaviour.

Looks like nv_connector->edid gets updated in .detect() as one might
expect, so in theory we might get a mismatch between the
drm_detect_monitor_audio(edid) check above and the actual eld contents
here if .detect() gets called without .get_modes(). Not a problem for
the probe helper's .fill_modes(), but eg. the poll helper does do that.

I guess we could always consider doing the edid_to_eld() already from
.detect()/.force() for all drivers if we think there would be a good
reason to populate the ELD even if .get_modes()/.fill_modes() hasn't
been called.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Maarten Lankhorst]

This introduces a slight behavioral change to rmfb. Instead of
disabling a crtc when the primary plane is disabled, we try to
preserve it.

Apart from old versions of the vmwgfx xorg driver, there is
nothing depending on rmfb disabling a crtc.

Vmwgfx' and simple kms helper atomic implementation rejects CRTC
enabled without plane, so we can do this safely.

If the atomic commit is rejected by the driver then we will still
fall back to the old behavior and turn off the crtc.

Changes since v1:
- Restart completely when rmfb with crtc on fails (Sean Paul).

Signed-off-by: Maarten Lankhorst 
Cc: Sean Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_framebuffer.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 2affe53f3fda..f0679468f421 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -765,14 +765,18 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
struct drm_plane *plane;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
-   int i, ret = 0;
+   int i, ret;
unsigned plane_mask;
+   bool disable_crtcs = false;
 
-   state = drm_atomic_state_alloc(dev);
-   if (!state)
-   return -ENOMEM;
-
+retry_disable:
drm_modeset_acquire_init(, 0);
+
+   state = drm_atomic_state_alloc(dev);
+   if (!state) {
+   ret = -ENOMEM;
+   goto out;
+   }
state->acquire_ctx = 
 
 retry:
@@ -793,7 +797,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
goto unlock;
}
 
-   if (plane_state->crtc->primary == plane) {
+   if (disable_crtcs && plane_state->crtc->primary == plane) {
struct drm_crtc_state *crtc_state;
 
crtc_state = drm_atomic_get_existing_crtc_state(state, 
plane_state->crtc);
@@ -818,6 +822,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
plane->old_fb = plane->fb;
}
 
+   /* This list is only filled when disable_crtcs is set. */
for_each_new_connector_in_state(state, conn, conn_state, i) {
ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
 
@@ -840,9 +845,15 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
 
drm_atomic_state_put(state);
 
+out:
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 
+   if (ret == -EINVAL && !disable_crtcs) {
+   disable_crtcs = true;
+   goto retry_disable;
+   }
+
return ret;
 }
 
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

[Ville Syrjälä]

On Wed, Nov 01, 2017 at 04:20:56PM +0200, Jani Nikula wrote:
> We were recently bitten by drm_edid_to_eld() clearing the connector
> type, and us failing to set it back for DP. Here's a few ELD related
> patches to try to unify ELD handling and make it a bit simpler for
> drivers to get it right.
> 
> Apologies for the massive Cc list; it's the maintainers of all drivers
> that call drm_edid_to_eld().
> 
> I'm open to splitting up patch 6 to driver specific patches as needed,
> but I'd think it would be just fine to merge via drm-misc as-is too.

Entire series lgtm so
Reviewed-by: Ville Syrjälä 

> 
> BR,
> Jani.
> 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Russell King 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> Cc: Ben Skeggs 
> Cc: Mark Yao 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Thierry Reding 
> Cc: Eric Anholt 
> 
> 
> Jani Nikula (7):
>   drm/edid: use macros for ELD offsets and values
>   drm/edid: set ELD connector type in drm_edid_to_eld()
>   drm/i915: remove redundant ELD connector type update
>   drm/edid: abstract connector ELD clearing
>   drm/edid: build ELD in drm_add_edid_modes()
>   drm/drivers: drop redundant drm_edid_to_eld() calls
>   drm/edid: make drm_edid_to_eld() static
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  1 -
>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  2 -
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  2 -
>  drivers/gpu/drm/drm_edid.c | 70 
> +++---
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  1 -
>  drivers/gpu/drm/i915/intel_dp.c|  1 -
>  drivers/gpu/drm/i915/intel_modes.c | 18 ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  1 -
>  drivers/gpu/drm/nouveau/nv50_display.c |  5 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c |  1 -
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  1 -
>  drivers/gpu/drm/rockchip/cdn-dp-core.c |  4 +-
>  drivers/gpu/drm/sti/sti_hdmi.c |  1 -
>  drivers/gpu/drm/tegra/output.c |  1 -
>  drivers/gpu/drm/vc4/vc4_hdmi.c |  1 -
>  include/drm/drm_edid.h |  1 -
>  include/drm/drm_modeset_helper_vtables.h   |  3 --
>  17 files changed, 44 insertions(+), 70 deletions(-)
> 
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Check that the breadcrumb wasn't disarmed automatically before parking

[Patchwork]

== Series Details ==

Series: drm/i915: Check that the breadcrumb wasn't disarmed automatically 
before parking
URL   : https://patchwork.freedesktop.org/series/32903/
State : failure

== Summary ==

Series 32903 revision 1 was fully merged or fully failed: no git log

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6279/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Re-enable fastboot by default

[Maarten Lankhorst]

This fix was originally reverted because it left a chromebook pixel
black, and no immediate fix was available. This has been fixed in the
meantime.

Rather than trying to remove the parameter, set it to default to true
for now, so we can always back out if required.

Signed-off-by: Maarten Lankhorst 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Testcase: kms_panel_fitting
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index e54e6a4bc6bd..396126aac932 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -57,7 +57,7 @@
param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \
param(bool, enable_cmd_parser, true) \
param(bool, enable_hangcheck, true) \
-   param(bool, fastboot, false) \
+   param(bool, fastboot, true) \
param(bool, prefault_disable, false) \
param(bool, load_detect_test, false) \
param(bool, force_reset_modeset_test, false) \
-- 
2.14.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/drm_vma_manager.c: Remove useless goto statement

[Chris Wilson]

Quoting Liviu Dudau (2017-11-01 14:44:58)
> Commit db2395eccf08i ("drm: Convert drm_vma_manager to embedded
> interval-tree in drm_mm") removed a line in drm_vma_offset_add() function that
> makes checking the result of calling drm_mm_insert_node() and the goto
> call redundant. Rework the function (as suggested by Chris Wilson) to
> eliminate the need for the goto and associated label.
> 
> v2: rewrite function to remove all goto statements.
> 
> Fixes: db2395eccf08i ("drm: Convert drm_vma_manager to embedded interval-tree 
> in drm_mm")
> Cc: Chris Wilson 
> Signed-off-by: Liviu Dudau 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Remove unsafe i915.enable_rc6

[Ben Widawsky]

On 17-11-01 14:07:28, Joonas Lahtinen wrote:

On Mon, 2017-10-30 at 10:48 -0700, Rodrigo Vivi wrote:

On Mon, Oct 30, 2017 at 01:00:51PM +, David Weinehall wrote:
> On Fri, Oct 27, 2017 at 01:57:09PM -0700, Daniele Ceraolo Spurio wrote:
> >
> >
> > On 26/10/17 03:32, Chris Wilson wrote:
> > > It has been many years since the last confirmed sighting (and fix) of an
> > > RC6 related bug (usually a system hang). Remove the parameter to stop
> > > users from setting dangerous values, as they often set it during triage
> > > and end up disabling the entire runtime pm instead (the option is not a
> > > fine scalpel!).
> > >
> > > Furthermore, it allows users to set known dangerous values which were
> > > intended for testing and not for production use. For testing, we can
> > > always patch in the required setting without having to expose ourselves
> > > to random abuse.
> > >
> > > v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the
> > > lack of ilk support better.
> > > v3: Clear intel_info->rc6p if we don't support rc6 itself.
> > >
> > > Signed-off-by: Chris Wilson 
> > > Cc: Rodrigo Vivi 
> > > Cc: Joonas Lahtinen 
> > > Cc: Jani Nikula 
> > > Cc: Imre Deak 
> > > Cc: Daniel Vetter 
> > > Acked-by: Daniel Vetter 
> > > ---
> >
> > I think that for execution/debug on early silicon we might still want the
> > ability to turn features like RC6 off. Maybe we can add a debug kconfig to
> > force info->has_rc6 = 0? Not a blocker to this patch but worth considering
> > IMO.
>
> Most of the BIOSes I've seen on our RVPs have had an option to disable
> RC6.

BIOS option don't block our code to run and set some MMIOs.
Not sure how the GPU will behave on such cases.

I like the idea of removing some and keeping the parameters clean.
But there are few ones like RC6 and disable_power_wells that are very
useful on platform enabling and also when assisting others to debug issues.

For instance right now that we fixed RC6 on CNL someone told that
he believe seeing more hangs, so I immediately asked to boot with
i915.enable_rc6=0 to double check. It is easier and straighforward
to direct them to the unsafe param than to ask them to compile the code
with different options or to use some BIOS options that we are not sure.

Also on bug triage some options like this are helpful.

Also BIOS and compile are saved flags. So if you need to do a quick test
you have to save it, and then unsave later. Parameters are very convinient
for 1 boot only check.


It's convenient for sure, but the unsafe module parameters seems to be
finding their way into way too many HOWTOs, and from there to some
"productized" use-cases. Chris states that setting .enable_rc6=0 to
solving an issue on publicly shipping products has been some years ago,
so I don't see a need for carrying this.

We shouldn't allow the convenience of not having to change one line and
recompile kernel during development to affect the end-users who are
Googling how to get the best performance out of their hardware (I could
mention some distro here).

This seems the like the best option as I don't think introducing kernel
parameters that only exists on debug builds would be too convenient
either. It'd maybe just add more confusion.

Regards, Joonas


I believe the ability to disable RC6 is valuable not just for debugging
purposes. Folks with very latency sensitive workloads are often willing to
forego power savings. The real problem I see is that we don't test without rc6
in our setup, which indeed makes it unsafe. As such, I see the other option here
going back to the ability to toggle rc6 after load (either module parameter, or
make it sysfs), and actually run some subset of our workloads with RC6. I
suspect people will poop on that suggestion, but I figured I'd mention.



--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Split GuC firmware xfer function into clear steps

[Sagar Arun Kamble]

On 11/1/2017 7:54 PM, Michal Wajdeczko wrote:
On Mon, 30 Oct 2017 15:00:52 +0100, Sagar Arun Kamble 
 wrote:





On 10/27/2017 10:45 PM, Michal Wajdeczko wrote:

Transfer of GuC firmware requires few steps that currently
are implemented in two large functions. Split this code into
smaller functions to make these steps small and clear.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_guc_fw.c | 173 
++--

  1 file changed, 106 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c

index ef67a36..2a10bcf 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -97,23 +97,53 @@ int intel_guc_fw_select(struct intel_guc *guc)
  return 0;
  }
  -/*
- * Read the GuC status register (GUC_STATUS) and store it in the
- * specified location; then return a boolean indicating whether
- * the value matches either of two values representing completion
- * of the GuC boot process.
- *
- * This is used for polling the GuC status in a wait_for()
- * loop below.
- */
-static inline bool guc_ucode_response(struct drm_i915_private 
*dev_priv,

-  u32 *status)
+static void guc_ucode_xfer_prepare(struct drm_i915_private *dev_priv)
  {
-    u32 val = I915_READ(GUC_STATUS);
-    u32 uk_val = val & GS_UKERNEL_MASK;
-    *status = val;
-    return (uk_val == GS_UKERNEL_READY ||
-    ((val & GS_MIA_CORE_STATE) && uk_val == 
GS_UKERNEL_LAPIC_DONE));

+    /* Enable MIA caching. GuC clock gating is disabled. */
Clock gating comment is linked with below WaDisableMinuteIa*. Can you 
update in this patch. Better to drop with Wa name telling the intent.

+    I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE);
+
+    /* WaDisableMinuteIaClockGating:bxt */
+    if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) {
+    I915_WRITE(GUC_SHIM_CONTROL, (I915_READ(GUC_SHIM_CONTROL) &
+  ~GUC_ENABLE_MIA_CLOCK_GATING));
+    }
+
+    /* WaC6DisallowByGfxPause:bxt */
+    if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_B0))
+    I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
+
+    if (IS_GEN9_LP(dev_priv))
+    I915_WRITE(GEN9LP_GT_PM_CONFIG, GT_DOORBELL_ENABLE);
+    else
+    I915_WRITE(GEN9_GT_PM_CONFIG, GT_DOORBELL_ENABLE);
+
+    if (IS_GEN9(dev_priv)) {
+    /* DOP Clock Gating Enable for GuC clocks */
+    I915_WRITE(GEN7_MISCCPCTL, (GEN8_DOP_CLOCK_GATE_GUC_ENABLE |
+    I915_READ(GEN7_MISCCPCTL)));
+
+    /* allows for 5us (in 10ns units) before GT can go to RC6 */
+    I915_WRITE(GUC_ARAT_C6DIS, 0x1FF);
+    }
+}
+
+/* Copy RSA signature from the fw image to HW for verification */
+static int guc_ucode_xfer_rsa(struct intel_uc_fw *guc_fw, struct 
i915_vma *vma)

+{
+    struct intel_guc *guc = container_of(guc_fw, struct intel_guc, 
fw);

+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+    struct sg_table *sg = vma->pages;
+    u32 rsa[UOS_RSA_SCRATCH_MAX_COUNT];
+    int i;
+
+    if (sg_pcopy_to_buffer(sg->sgl, sg->nents, rsa, sizeof(rsa),
+   guc_fw->rsa_offset) != sizeof(rsa))
+    return -EINVAL;
+
+    for (i = 0; i < UOS_RSA_SCRATCH_MAX_COUNT; i++)
+    I915_WRITE(UOS_RSA_SCRATCH(i), rsa[i]);
+
+    return 0;
  }
    /*
@@ -122,29 +152,19 @@ static inline bool guc_ucode_response(struct 
drm_i915_private *dev_priv,
   * Architecturally, the DMA engine is bidirectional, and can 
potentially even
   * transfer between GTT locations. This functionality is left out 
of the API

   * for now as there is no need for it.
- *
- * Note that GuC needs the CSS header plus uKernel code to be 
copied by the
- * DMA engine in one operation, whereas the RSA signature is loaded 
via MMIO.

   */
-static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv,
-  struct i915_vma *vma)
+static int guc_ucode_xfer_dma(struct intel_uc_fw *guc_fw, struct 
i915_vma *vma)

  {
-    struct intel_uc_fw *guc_fw = _priv->guc.fw;
+    struct intel_guc *guc = container_of(guc_fw, struct intel_guc, 
fw);

+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
  unsigned long offset;
-    struct sg_table *sg = vma->pages;
-    u32 status, rsa[UOS_RSA_SCRATCH_MAX_COUNT];
-    int i, ret = 0;
-
-    /* where RSA signature starts */
-    offset = guc_fw->rsa_offset;
-
-    /* Copy RSA signature from the fw image to HW for verification */
-    sg_pcopy_to_buffer(sg->sgl, sg->nents, rsa, sizeof(rsa), offset);
-    for (i = 0; i < UOS_RSA_SCRATCH_MAX_COUNT; i++)
-    I915_WRITE(UOS_RSA_SCRATCH(i), rsa[i]);
+    u32 status;
+    int ret;
  -    /* The header plus uCode will be copied to WOPCM via DMA, 
excluding any

- * other components */
+    /*
+ * The header plus 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Warn in debug builds of incorrect usages of ptr_pack_bits

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-10-31 10:23:26)
> From: Tvrtko Ursulin 
> 
> GEM_BUG_ON if the packed bits do not fit into the specified width.
> 
> Signed-off-by: Tvrtko Ursulin 

Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Reject unknown syncobj flags

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-10-31 10:23:25)
> From: Tvrtko Ursulin 
> 
> We have to reject unknown flags for uAPI considerations, and also
> because the curent implementation limits their i915 storage space
> to two bits.
> 
> v2: (Chris Wilson)
>  * Fix fail in ABI check.
>  * Added unknown flags and BUILD_BUG_ON.
> 
> v3:
>  * Use ARCH_KMALLOC_MINALIGN instead of alignof. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: cf6e7bac6357 ("drm/i915: Add support for drm syncobjs")
> Cc: Jason Ekstrand 
> Cc: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 
>  include/uapi/drm/i915_drm.h| 1 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 3d7190764f10..a53be7d01055 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -2100,6 +2100,11 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
> goto err;
> }
>  
> +   if (fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
> +   err = -EINVAL;
> +   goto err;
> +   }
> +
> syncobj = drm_syncobj_find(file, fence.handle);
> if (!syncobj) {
> DRM_DEBUG("Invalid syncobj handle provided\n");
> @@ -2107,6 +2112,9 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
> goto err;
> }
>  
> +   BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
> +~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
> +
> fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);

Was pondering how to tie the .n=2 into the BUILD_BUG_ON, but that
doesn't limit the improvement and fixes in this patch, so

Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Split GuC firmware xfer function into clear steps

[Michal Wajdeczko]

On Mon, 30 Oct 2017 15:00:52 +0100, Sagar Arun Kamble  
 wrote:





On 10/27/2017 10:45 PM, Michal Wajdeczko wrote:

Transfer of GuC firmware requires few steps that currently
are implemented in two large functions. Split this code into
smaller functions to make these steps small and clear.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
---
  drivers/gpu/drm/i915/intel_guc_fw.c | 173  
++--

  1 file changed, 106 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c  
b/drivers/gpu/drm/i915/intel_guc_fw.c

index ef67a36..2a10bcf 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -97,23 +97,53 @@ int intel_guc_fw_select(struct intel_guc *guc)
return 0;
  }
  -/*
- * Read the GuC status register (GUC_STATUS) and store it in the
- * specified location; then return a boolean indicating whether
- * the value matches either of two values representing completion
- * of the GuC boot process.
- *
- * This is used for polling the GuC status in a wait_for()
- * loop below.
- */
-static inline bool guc_ucode_response(struct drm_i915_private  
*dev_priv,

- u32 *status)
+static void guc_ucode_xfer_prepare(struct drm_i915_private *dev_priv)
  {
-   u32 val = I915_READ(GUC_STATUS);
-   u32 uk_val = val & GS_UKERNEL_MASK;
-   *status = val;
-   return (uk_val == GS_UKERNEL_READY ||
-   ((val & GS_MIA_CORE_STATE) && uk_val == GS_UKERNEL_LAPIC_DONE));
+   /* Enable MIA caching. GuC clock gating is disabled. */
Clock gating comment is linked with below WaDisableMinuteIa*. Can you  
update in this patch. Better to drop with Wa name telling the intent.

+   I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE);
+
+   /* WaDisableMinuteIaClockGating:bxt */
+   if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1)) {
+   I915_WRITE(GUC_SHIM_CONTROL, (I915_READ(GUC_SHIM_CONTROL) &
+ ~GUC_ENABLE_MIA_CLOCK_GATING));
+   }
+
+   /* WaC6DisallowByGfxPause:bxt */
+   if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_B0))
+   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
+
+   if (IS_GEN9_LP(dev_priv))
+   I915_WRITE(GEN9LP_GT_PM_CONFIG, GT_DOORBELL_ENABLE);
+   else
+   I915_WRITE(GEN9_GT_PM_CONFIG, GT_DOORBELL_ENABLE);
+
+   if (IS_GEN9(dev_priv)) {
+   /* DOP Clock Gating Enable for GuC clocks */
+   I915_WRITE(GEN7_MISCCPCTL, (GEN8_DOP_CLOCK_GATE_GUC_ENABLE |
+   I915_READ(GEN7_MISCCPCTL)));
+
+   /* allows for 5us (in 10ns units) before GT can go to RC6 */
+   I915_WRITE(GUC_ARAT_C6DIS, 0x1FF);
+   }
+}
+
+/* Copy RSA signature from the fw image to HW for verification */
+static int guc_ucode_xfer_rsa(struct intel_uc_fw *guc_fw, struct  
i915_vma *vma)

+{
+   struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw);
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct sg_table *sg = vma->pages;
+   u32 rsa[UOS_RSA_SCRATCH_MAX_COUNT];
+   int i;
+
+   if (sg_pcopy_to_buffer(sg->sgl, sg->nents, rsa, sizeof(rsa),
+  guc_fw->rsa_offset) != sizeof(rsa))
+   return -EINVAL;
+
+   for (i = 0; i < UOS_RSA_SCRATCH_MAX_COUNT; i++)
+   I915_WRITE(UOS_RSA_SCRATCH(i), rsa[i]);
+
+   return 0;
  }
/*
@@ -122,29 +152,19 @@ static inline bool guc_ucode_response(struct  
drm_i915_private *dev_priv,
   * Architecturally, the DMA engine is bidirectional, and can  
potentially even
   * transfer between GTT locations. This functionality is left out of  
the API

   * for now as there is no need for it.
- *
- * Note that GuC needs the CSS header plus uKernel code to be copied  
by the
- * DMA engine in one operation, whereas the RSA signature is loaded  
via MMIO.

   */
-static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv,
- struct i915_vma *vma)
+static int guc_ucode_xfer_dma(struct intel_uc_fw *guc_fw, struct  
i915_vma *vma)

  {
-   struct intel_uc_fw *guc_fw = _priv->guc.fw;
+   struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw);
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
unsigned long offset;
-   struct sg_table *sg = vma->pages;
-   u32 status, rsa[UOS_RSA_SCRATCH_MAX_COUNT];
-   int i, ret = 0;
-
-   /* where RSA signature starts */
-   offset = guc_fw->rsa_offset;
-
-   /* Copy RSA signature from the fw image to HW for verification */
-   sg_pcopy_to_buffer(sg->sgl, sg->nents, rsa, sizeof(rsa), offset);
-   for (i = 0; i < UOS_RSA_SCRATCH_MAX_COUNT; i++)
-   

Re: [Intel-gfx] [PATCH i-g-t] kms_atomic_transition: Add subtest time limit/randomize plane, pipe combinations

[Maarten Lankhorst]

Op 01-11-17 om 13:55 schreef Imre Deak:
> On Wed, Nov 01, 2017 at 12:32:37PM +0100, Maarten Lankhorst wrote:
>> Op 31-10-17 om 14:44 schreef Imre Deak:
>>> Doing modeset on internal panels may have a considerable overhead due to
>>> the panel specific power sequencing delays. To avoid long test runtimes
>>> limit the runtime of each subtest. Randomize the plane/pipe combinations
>>> to preserve the test coverage on such panels at least over multiple test
>>> runs.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103334
>>> Cc: Maarten Lankhorst 
>>> Signed-off-by: Imre Deak 
>>> ---
>>>  tests/kms_atomic_transition.c | 175 
>>> --
>>>  1 file changed, 150 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
>>> index 4c295125..ac67fc3a 100644
>>> --- a/tests/kms_atomic_transition.c
>>> +++ b/tests/kms_atomic_transition.c
>>> @@ -39,6 +39,14 @@
>>>  #define DRM_CAP_CURSOR_HEIGHT 0x9
>>>  #endif
>>>  
>>> +#define MAX_SUBTEST_DURATION_NS (20ULL * NSEC_PER_SEC)
>>> +
>>> +struct test_config {
>>> +   igt_display_t *display;
>>> +   bool user_seed;
>>> +   int seed;
>>> +};
>>> +
>>>  struct plane_parms {
>>> struct igt_fb *fb;
>>> uint32_t width, height;
>>> @@ -401,6 +409,28 @@ static void wait_for_transition(igt_display_t 
>>> *display, enum pipe pipe, bool non
>>> }
>>>  }
>>>  
>>> +/* Copied from https://benpfaff.org/writings/clc/shuffle.html */
>>> +static void shuffle_array(uint32_t *array, int size, int seed)
>>> +{
>>> +   int i;
>>> +
>>> +   for (i = 0; i < size; i++) {
>>> +   int j = i + rand() / (RAND_MAX / (size - i) + 1);
>>> +
>>> +   igt_swap(array[i], array[j]);
>>> +   }
>>> +}
>> I wouldn't worry about predictibility of the random number generator..
>>
>> int j = i + rand() % (size - i) is good enough and easier to read. :)
> Chris already suggested igt_permute_array(), will use that.
>
>> I think the struct test_config can be killed too, since it goes unused
>> in shuffle_array, nothing in the test uses it...
> Oops, some kind of left-over from an earlier version. Thanks for spotting
> it.
>
>>> +static void init_combination_array(uint32_t *array, int size, int seed)
>>> +{
>>> +   int i;
>>> +
>>> +   for (i = 0; i < size; i++)
>>> +   array[i] = i;
>>> +
>>> +   shuffle_array(array, size, seed);
>>> +}
>>> +
>>>  /*
>>>   * 1. Set primary plane to a known fb.
>>>   * 2. Make sure getcrtc returns the correct fb id.
>>> @@ -411,19 +441,27 @@ static void wait_for_transition(igt_display_t 
>>> *display, enum pipe pipe, bool non
>>>   * so test this and make sure it works.
>>>   */
>>>  static void
>>> -run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t 
>>> *output,
>>> -   enum transition_type type, bool nonblocking, bool fencing)
>>> +run_transition_test(struct test_config *test_config, enum pipe pipe,
>>> +   igt_output_t *output, enum transition_type type,
>>> +   bool nonblocking, bool fencing)
>>>  {
>>> struct igt_fb fb, argb_fb, sprite_fb;
>>> drmModeModeInfo *mode, override_mode;
>>> +   igt_display_t *display = test_config->display;
>>> igt_plane_t *plane;
>>> igt_pipe_t *pipe_obj = >pipes[pipe];
>>> uint32_t iter_max = 1 << pipe_obj->n_planes, i;
>>> +   uint32_t *plane_combinations;
>>> +   struct timespec start = { };
>>> struct plane_parms parms[pipe_obj->n_planes];
>>> bool skip_test = false;
>>> unsigned flags = 0;
>>> int ret;
>>>  
>>> +   plane_combinations = malloc(sizeof(*plane_combinations) * iter_max);
>>> +   igt_assert(plane_combinations);
>>> +   init_combination_array(plane_combinations, iter_max, test_config->seed);
>> It would be cleaner to have a separate test for transition_modeset.
>> The rest should be run to completion and don't need shuffling, since
>> in normal cases, they'll never hit a timeout.
> Do you mean type == TRANSITION_MODESET? There are already separate
> subtests for that. Yes, can disable the timeout and shuffling for the
> rest.
>
>> So make a separate test for that, and perhaps also add a flag for
>> disabling the timeout.
> Ok.
>
>>> if (fencing)
>>> prepare_fencing(display, pipe);
>>> else
>>> @@ -527,39 +565,59 @@ run_transition_test(igt_display_t *display, enum pipe 
>>> pipe, igt_output_t *output
>>> goto cleanup;
>>> }
>>>  
>>> +   igt_nsec_elapsed();
>>> +
>>> for (i = 0; i < iter_max; i++) {
>>> igt_output_set_pipe(output, pipe);
>>>  
>>> -   wm_setup_plane(display, pipe, i, parms, fencing);
>>> +   wm_setup_plane(display, pipe, plane_combinations[i], parms,
>>> +  fencing);
>>>  
>>> -   atomic_commit(display, pipe, flags, (void *)(unsigned long)i, 
>>> fencing);
>>> +   atomic_commit(display, pipe, flags,
>>> +

[Intel-gfx] [PATCH 4/7] drm/edid: abstract connector ELD clearing

[Jani Nikula]

Preparation for future work. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3139c2e90e32..3162ea58e450 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3829,6 +3829,18 @@ void drm_edid_get_monitor_name(struct edid *edid, char 
*name, int bufsize)
 }
 EXPORT_SYMBOL(drm_edid_get_monitor_name);
 
+static void clear_eld(struct drm_connector *connector)
+{
+   memset(connector->eld, 0, sizeof(connector->eld));
+
+   connector->latency_present[0] = false;
+   connector->latency_present[1] = false;
+   connector->video_latency[0] = 0;
+   connector->audio_latency[0] = 0;
+   connector->video_latency[1] = 0;
+   connector->audio_latency[1] = 0;
+}
+
 /**
  * drm_edid_to_eld - build ELD from EDID
  * @connector: connector corresponding to the HDMI/DP sink
@@ -3846,14 +3858,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
int mnl;
int dbl;
 
-   memset(eld, 0, sizeof(connector->eld));
-
-   connector->latency_present[0] = false;
-   connector->latency_present[1] = false;
-   connector->video_latency[0] = 0;
-   connector->audio_latency[0] = 0;
-   connector->video_latency[1] = 0;
-   connector->audio_latency[1] = 0;
+   clear_eld(connector);
 
if (!edid)
return;
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/7] drm/drivers: drop redundant drm_edid_to_eld() calls

[Jani Nikula]

drm_add_edid_modes() now fills in the ELD automatically, so the calls to
drm_edid_to_eld() are redundant. Remove them.

All the other places are obvious, but nv50 has detached
drm_edid_to_eld() from the drm_add_edid_modes() call.

Cc: Alex Deucher 
Cc: Christian König 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Russell King 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Ben Skeggs 
Cc: Mark Yao 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Thierry Reding 
Cc: Eric Anholt 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 -
 drivers/gpu/drm/bridge/analogix-anx78xx.c  | 2 --
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  | 2 --
 drivers/gpu/drm/i2c/tda998x_drv.c  | 1 -
 drivers/gpu/drm/i915/intel_dp.c| 1 -
 drivers/gpu/drm/i915/intel_modes.c | 1 -
 drivers/gpu/drm/mediatek/mtk_hdmi.c| 1 -
 drivers/gpu/drm/nouveau/nv50_display.c | 5 +
 drivers/gpu/drm/radeon/radeon_connectors.c | 1 -
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 1 -
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +---
 drivers/gpu/drm/sti/sti_hdmi.c | 1 -
 drivers/gpu/drm/tegra/output.c | 1 -
 drivers/gpu/drm/vc4/vc4_hdmi.c | 1 -
 14 files changed, 2 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index df9cbc78e168..8ca3783f2deb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -358,7 +358,6 @@ static int amdgpu_connector_ddc_get_modes(struct 
drm_connector *connector)
if (amdgpu_connector->edid) {
drm_mode_connector_update_edid_property(connector, 
amdgpu_connector->edid);
ret = drm_add_edid_modes(connector, amdgpu_connector->edid);
-   drm_edid_to_eld(connector, amdgpu_connector->edid);
return ret;
}
drm_mode_connector_update_edid_property(connector, NULL);
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 9385eb0b1ee4..ed12a7ddd64a 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -977,8 +977,6 @@ static int anx78xx_get_modes(struct drm_connector 
*connector)
}
 
num_modes = drm_add_edid_modes(connector, anx78xx->edid);
-   /* Store the ELD */
-   drm_edid_to_eld(connector, anx78xx->edid);
 
 unlock:
mutex_unlock(>lock);
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..a64ce7112288 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1910,8 +1910,6 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
drm_mode_connector_update_edid_property(connector, edid);
cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
ret = drm_add_edid_modes(connector, edid);
-   /* Store the ELD */
-   drm_edid_to_eld(connector, edid);
kfree(edid);
} else {
dev_dbg(hdmi->dev, "failed to get edid\n");
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 4d1f45acf2cd..60981505763c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1100,7 +1100,6 @@ static int tda998x_connector_get_modes(struct 
drm_connector *connector)
 
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
 
kfree(edid);
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d27c0145ac91..cddd96b24878 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5889,7 +5889,6 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
if (drm_add_edid_modes(connector, edid)) {
drm_mode_connector_update_edid_property(connector,
edid);
-   drm_edid_to_eld(connector, edid);
} else {
kfree(edid);
edid = ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index 951e834dd274..b39846613e3c 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -42,7 +42,6 @@ int 

[Intel-gfx] [PATCH 7/7] drm/edid: make drm_edid_to_eld() static

[Jani Nikula]

This is no longer needed outside of drm_edid.c.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c   | 5 ++---
 include/drm/drm_edid.h   | 1 -
 include/drm/drm_modeset_helper_vtables.h | 3 ---
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4e3ef3d91b95..749d07a01772 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3841,7 +3841,7 @@ static void clear_eld(struct drm_connector *connector)
connector->audio_latency[1] = 0;
 }
 
-/**
+/*
  * drm_edid_to_eld - build ELD from EDID
  * @connector: connector corresponding to the HDMI/DP sink
  * @edid: EDID to parse
@@ -3849,7 +3849,7 @@ static void clear_eld(struct drm_connector *connector)
  * Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
  * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
  */
-void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
+static void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
 {
uint8_t *eld = connector->eld;
u8 *cea;
@@ -3934,7 +3934,6 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
DRM_DEBUG_KMS("ELD size %d, SAD count %d\n",
  drm_eld_size(eld), total_sad_count);
 }
-EXPORT_SYMBOL(drm_edid_to_eld);
 
 /**
  * drm_edid_to_sad - extracts SADs from EDID
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 6f35909b8add..9e4e23524840 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -333,7 +333,6 @@ struct drm_encoder;
 struct drm_connector;
 struct drm_display_mode;
 
-void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
 int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
 int drm_av_sync_delay(struct drm_connector *connector,
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index 16646c44b7df..3e76ca805b0f 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -801,9 +801,6 @@ struct drm_connector_helper_funcs {
 * resolution can call drm_add_modes_noedid(), and mark the preferred
 * one using drm_set_preferred_mode().
 *
-* Finally drivers that support audio probably want to update the ELD
-* data, too, using drm_edid_to_eld().
-*
 * This function is only called after the @detect hook has indicated
 * that a sink is connected and when the EDID isn't overridden through
 * sysfs or the kernel commandline.
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/7] drm/edid: build ELD in drm_add_edid_modes()

[Jani Nikula]

Call drm_edid_to_eld() from drm_add_edid_modes() to fill in the ELD
automatically. There's no harm in doing this for connectors that do not
support audio.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3162ea58e450..4e3ef3d91b95 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4612,8 +4612,8 @@ static int add_displayid_detailed_modes(struct 
drm_connector *connector,
  * @edid: EDID data
  *
  * Add the specified modes to the connector's mode list. Also fills out the
- * _display_info structure in @connector with any information which can be
- * derived from the edid.
+ * _display_info structure and ELD in @connector with any information which
+ * can be derived from the edid.
  *
  * Return: The number of modes added or 0 if we couldn't find any.
  */
@@ -4623,9 +4623,11 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
u32 quirks;
 
if (edid == NULL) {
+   clear_eld(connector);
return 0;
}
if (!drm_edid_is_valid(edid)) {
+   clear_eld(connector);
dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
 connector->name);
return 0;
@@ -4633,6 +4635,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
 
quirks = edid_get_quirks(edid);
 
+   drm_edid_to_eld(connector, edid);
+
/*
 * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
 * To avoid multiple parsing of same block, lets parse that map
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/7] drm/i915: remove redundant ELD connector type update

[Jani Nikula]

drm_edid_to_eld() now sets ELD connector type, remove the redundant
update.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_modes.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_modes.c 
b/drivers/gpu/drm/i915/intel_modes.c
index 28a778b785ac..951e834dd274 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -30,21 +30,6 @@
 #include "intel_drv.h"
 #include "i915_drv.h"
 
-static void intel_connector_update_eld_conn_type(struct drm_connector 
*connector)
-{
-   u8 conn_type;
-
-   if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
-   connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
-   conn_type = DRM_ELD_CONN_TYPE_DP;
-   } else {
-   conn_type = DRM_ELD_CONN_TYPE_HDMI;
-   }
-
-   connector->eld[DRM_ELD_SAD_COUNT_CONN_TYPE] &= ~DRM_ELD_CONN_TYPE_MASK;
-   connector->eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= conn_type;
-}
-
 /**
  * intel_connector_update_modes - update connector from edid
  * @connector: DRM connector device to use
@@ -59,8 +44,6 @@ int intel_connector_update_modes(struct drm_connector 
*connector,
ret = drm_add_edid_modes(connector, edid);
drm_edid_to_eld(connector, edid);
 
-   intel_connector_update_eld_conn_type(connector);
-
return ret;
 }
 
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/7] drm/edid: set ELD connector type in drm_edid_to_eld()

[Jani Nikula]

Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.

For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.

Cc: Alex Deucher 
Cc: Christian König 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Russell King 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Ben Skeggs 
Cc: Mark Yao 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Thierry Reding 
Cc: Eric Anholt 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6229735ecc15..3139c2e90e32 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3835,8 +3835,7 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name);
  * @edid: EDID to parse
  *
  * Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
- * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to
- * fill in.
+ * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
  */
 void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
 {
@@ -3918,6 +3917,12 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
}
eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= total_sad_count << 
DRM_ELD_SAD_COUNT_SHIFT;
 
+   if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+   connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+   eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP;
+   else
+   eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI;
+
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
 
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

[Jani Nikula]

We were recently bitten by drm_edid_to_eld() clearing the connector
type, and us failing to set it back for DP. Here's a few ELD related
patches to try to unify ELD handling and make it a bit simpler for
drivers to get it right.

Apologies for the massive Cc list; it's the maintainers of all drivers
that call drm_edid_to_eld().

I'm open to splitting up patch 6 to driver specific patches as needed,
but I'd think it would be just fine to merge via drm-misc as-is too.

BR,
Jani.

Cc: Alex Deucher 
Cc: Christian König 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Russell King 
Cc: CK Hu 
Cc: Philipp Zabel 
Cc: Ben Skeggs 
Cc: Mark Yao 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Thierry Reding 
Cc: Eric Anholt 


Jani Nikula (7):
  drm/edid: use macros for ELD offsets and values
  drm/edid: set ELD connector type in drm_edid_to_eld()
  drm/i915: remove redundant ELD connector type update
  drm/edid: abstract connector ELD clearing
  drm/edid: build ELD in drm_add_edid_modes()
  drm/drivers: drop redundant drm_edid_to_eld() calls
  drm/edid: make drm_edid_to_eld() static

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  1 -
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |  2 -
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  2 -
 drivers/gpu/drm/drm_edid.c | 70 +++---
 drivers/gpu/drm/i2c/tda998x_drv.c  |  1 -
 drivers/gpu/drm/i915/intel_dp.c|  1 -
 drivers/gpu/drm/i915/intel_modes.c | 18 ---
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  1 -
 drivers/gpu/drm/nouveau/nv50_display.c |  5 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |  1 -
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  1 -
 drivers/gpu/drm/rockchip/cdn-dp-core.c |  4 +-
 drivers/gpu/drm/sti/sti_hdmi.c |  1 -
 drivers/gpu/drm/tegra/output.c |  1 -
 drivers/gpu/drm/vc4/vc4_hdmi.c |  1 -
 include/drm/drm_edid.h |  1 -
 include/drm/drm_modeset_helper_vtables.h   |  3 --
 17 files changed, 44 insertions(+), 70 deletions(-)

-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/7] drm/edid: use macros for ELD offsets and values

[Jani Nikula]

We have the macros, use them. No functional changes.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00ddabfbf980..6229735ecc15 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3756,8 +3756,8 @@ drm_parse_hdmi_vsdb_audio(struct drm_connector 
*connector, const u8 *db)
 {
u8 len = cea_db_payload_len(db);
 
-   if (len >= 6)
-   connector->eld[5] |= (db[6] >> 7) << 1;  /* Supports_AI */
+   if (len >= 6 && (db[6] & (1 << 7)))
+   connector->eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= 
DRM_ELD_SUPPORTS_AI;
if (len >= 8) {
connector->latency_present[0] = db[8] >> 7;
connector->latency_present[1] = (db[8] >> 6) & 1;
@@ -3865,17 +3865,18 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
return;
}
 
-   mnl = get_monitor_name(edid, eld + 20);
+   mnl = get_monitor_name(edid, [DRM_ELD_MONITOR_NAME_STRING]);
+   DRM_DEBUG_KMS("ELD monitor %s\n", [DRM_ELD_MONITOR_NAME_STRING]);
 
-   eld[4] = (cea[1] << 5) | mnl;
-   DRM_DEBUG_KMS("ELD monitor %s\n", eld + 20);
+   eld[DRM_ELD_CEA_EDID_VER_MNL] = cea[1] << DRM_ELD_CEA_EDID_VER_SHIFT;
+   eld[DRM_ELD_CEA_EDID_VER_MNL] |= mnl;
 
-   eld[0] = 2 << 3;/* ELD version: 2 */
+   eld[DRM_ELD_VER] = DRM_ELD_VER_CEA861D;
 
-   eld[16] = edid->mfg_id[0];
-   eld[17] = edid->mfg_id[1];
-   eld[18] = edid->prod_code[0];
-   eld[19] = edid->prod_code[1];
+   eld[DRM_ELD_MANUFACTURER_NAME0] = edid->mfg_id[0];
+   eld[DRM_ELD_MANUFACTURER_NAME1] = edid->mfg_id[1];
+   eld[DRM_ELD_PRODUCT_CODE0] = edid->prod_code[0];
+   eld[DRM_ELD_PRODUCT_CODE1] = edid->prod_code[1];
 
if (cea_revision(cea) >= 3) {
int i, start, end;
@@ -3896,14 +3897,14 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
/* Audio Data Block, contains SADs */
sad_count = min(dbl / 3, 15 - total_sad_count);
if (sad_count >= 1)
-   memcpy(eld + 20 + mnl + total_sad_count 
* 3,
+   memcpy([DRM_ELD_CEA_SAD(mnl, 
total_sad_count)],
   [1], sad_count * 3);
total_sad_count += sad_count;
break;
case SPEAKER_BLOCK:
/* Speaker Allocation Data Block */
if (dbl >= 1)
-   eld[7] = db[1];
+   eld[DRM_ELD_SPEAKER] = db[1];
break;
case VENDOR_BLOCK:
/* HDMI Vendor-Specific Data Block */
@@ -3915,7 +3916,7 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
}
}
}
-   eld[5] |= total_sad_count << 4;
+   eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= total_sad_count << 
DRM_ELD_SAD_COUNT_SHIFT;
 
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all

[Chris Wilson]

Quoting Daniel Vetter (2017-10-31 16:38:26)
> On Tue, Oct 31, 2017 at 03:28:01PM +0200, Ville Syrjälä wrote:
> > On Tue, Oct 31, 2017 at 11:55:35AM +, Chris Wilson wrote:
> > > To acquire all modeset locks requires a ww_ctx to be allocated. As this
> > > is the legacy path and the allocation small, to reduce the changes
> > > required (and complex untested error handling) to the legacy drivers, we
> > > simply assume that the allocation succeeds. At present, it relies on the
> > > too-small-to-fail rule, but syzbot found that by injecting a failure
> > > here we would hit the WARN. Document that this allocation must succeed
> > > with __GFP_NOFAIL.
> 
> Note that for atomic drivers at least all the core/helper paths are fixed
> up correctly. But e.g. i915 has still plenty of callsites in its own code,
> mostly debugfs.
> 
> > > Reported-by: syzbot (syzkaller)
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > 
> > Reviewed-by: Ville Syrjälä 
> 
> Applied, thanks.

Just curious as it hasn't shown up in drm-tip yet, so I'm worrying if it
found a crack to hide in.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Add support for reset engine using GuC commands

[Chris Wilson]

Quoting Michel Thierry (2017-10-31 22:53:09)
> This patch adds per engine reset and recovery (TDR) support when GuC is
> used to submit workloads to GPU.
> 
> In the case of i915 directly submission to ELSP, driver manages hang
> detection, recovery and resubmission. With GuC submission these tasks
> are shared between driver and GuC. i915 is still responsible for detecting
> a hang, and when it does it only requests GuC to reset that Engine. GuC
> internally manages acquiring forcewake and idling the engine before
> resetting it.
> 
> Once the reset is successful, i915 takes over again and handles the
> resubmission. The scheduler in i915 knows which requests are pending so
> after resetting a engine, pending workloads/requests are resubmitted
> again.
> 
> v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the
> non-guc function names.
> 
> v3: Removed debug message about engine restarting from which request,
> since the new baseline do it regardless of submission mode. (Chris)
> 
> v4: Rebase.
> 
> v5: Do not pass unnecessary reporting flags to the fw (Jeff);
> tasklet_schedule(>irq_tasklet) handles the resubmit; rebase.
> 
> v6: Rename the existing reset engine function and share a similar
> interface between guc and non-guc paths (Chris).
> 
> Signed-off-by: Michel Thierry 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.c   | 15 +--
>  drivers/gpu/drm/i915/i915_drv.h   |  2 ++
>  drivers/gpu/drm/i915/intel_guc.c  | 24 
>  drivers/gpu/drm/i915/intel_guc_fwif.h |  1 +
>  drivers/gpu/drm/i915/intel_uncore.c   |  5 -
>  5 files changed, 40 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index af745749509c..359333a423cf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1950,6 +1950,12 @@ void i915_reset(struct drm_i915_private *i915, 
> unsigned int flags)
> goto finish;
>  }
>  
> +static inline int intel_gt_reset_engine(struct drm_i915_private *dev_priv,
> +   struct intel_engine_cs *engine)
> +{
> +   return intel_gpu_reset(dev_priv, intel_engine_flag(engine));
> +}
> +
>  /**
>   * i915_reset_engine - reset GPU engine to recover from a hang
>   * @engine: engine to reset
> @@ -1984,10 +1990,15 @@ int i915_reset_engine(struct intel_engine_cs *engine, 
> unsigned int flags)
> goto out;
> }
>  
> -   ret = intel_gpu_reset(engine->i915, intel_engine_flag(engine));
> +   if (!engine->i915->guc.execbuf_client)
> +   ret = intel_gt_reset_engine(engine->i915, engine);
> +   else
> +   ret = intel_guc_reset_engine(>i915->guc, engine);
> +
> if (ret) {
> /* If we fail here, we expect to fallback to a global reset */
> -   DRM_DEBUG_DRIVER("Failed to reset %s, ret=%d\n",
> +   DRM_DEBUG_DRIVER("%sFailed to reset %s, ret=%d\n",
> +(engine->i915->guc.execbuf_client ? "GUC 
> ":""),

A bit overkill on the parentheses there ;)

Lgtm, can you please ping, say, Jeff or Daniele for an r-b on the guc
interaction?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check that the breadcrumb wasn't disarmed automatically before parking

[Chris Wilson]

Quoting Joonas Lahtinen (2017-11-01 13:38:19)
> On Tue, 2017-10-31 at 12:22 +, Chris Wilson wrote:
> > We will disarm the breadcrumb interrupt if we see a user interrupt
> > whilst no one is waiting. This may race with the call to
> > intel_engine_disarm_breadcrumbs() triggering an assert that we aren't
> > trying to do the same job twice. Prevent this by checking that the irq
> > is still armed after flushing the interrupt (for the irq spinlock).
> > 
> > Fixes: bcbd5c33a342 ("drm/i915/guc: Always enable the breadcrumbs irq")
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Cc: Michał Winiarski 
> 
> Reviewed-by: Joonas Lahtinen 

I'm still kicking myself for missing this in the first place. Thanks,
and pushed. Sadly I can't find a bugzilla for the oops hit by CI.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

[Chris Wilson]

Quoting David Weinehall (2017-11-01 13:38:48)
> On Tue, Oct 31, 2017 at 05:11:20PM -0700, Anusha Srivatsa wrote:
> > Calculate the time that GuC takes to load using
> > jiffies. This information could be very useful in
> > determining if GuC is taking unreasonably long time
> > to load in a certain platforms.
> > 
> > v2: Calculate time before logs are collected.
> > Move the guc_load_time variable as a part of
> > intel_uc_fw struct. Store only final result
> > which is to be exported to debugfs. (Michal)
> > Add the load time in the print message as well.
> > 
> > v3: Remove debugfs entry. Remove local variable
> > guc_finish_load. (Daniel, Tvrtko)
> > 
> > v4: Use ktime_get() instead of jiffies. Use DRM_NOTE
> > if time taken to load is more than the threshold. On
> > load times within acceptable range, use DRM_DEBUG_DRIVER
> > (Tvrtko)
> > 
> > v5: Rebased. Do not expose the load time variable in a global
> > struct (Tvrtko, Joonas)
> 
> From my point of view (measuring suspend/resume times) knowing
> how much time is spent loading GuC & HuC is really useful,
> so it's definitely useful information.

This information could be gleaned from ftrace...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

[Chris Wilson]

Quoting Joonas Lahtinen (2017-11-01 13:17:11)
> On Tue, 2017-10-31 at 10:36 +, Chris Wilson wrote:
> > In case the object has changed tiling between calls to execbuf, we need
> > to check if the existing offset inside the GTT matches the new tiling
> > constraint. We even need to do this for "unfenced" tiled objects, where
> > the 3D commands use an implied fence and so the object still needs to
> > match the physical fence restrictions on alignment (only required for
> > gen2 and early gen3).
> > 
> > In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
> > the execobjects array"), the idea was to remove the second guessing and
> > only set the NEEDS_MAP flag when required. However, the entire check
> > for an unusable offset for fencing was removed and not just the
> > secondary check. I.e.
> > 
> >   /* avoid costly ping-pong once a batch bo ended up non-mappable */
> > if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
> > !i915_vma_is_map_and_fenceable(vma))
> > return !only_mappable_for_reloc(entry->flags);
> > 
> > was entirely removed as the ping-pong between execbuf passes was fixed,
> > but its primary purpose in forcing unaligned unfenced access to be
> > rebound was forgotten.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
> > Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the 
> > execobjects array")
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

Ta. So I'd been pondering how to catch this in CI. In theory, this could
be caught by gem_render_tiled_blit, but it firstly requires checking
that the rendercopy routines use the implicit fence instructions and
secondary we need lots of repetitions with interleaved set-tiling to try
and cause an address conflict. And then we have only one machine in the
farm that is even susceptible to this bug...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

[David Weinehall]

On Tue, Oct 31, 2017 at 05:11:20PM -0700, Anusha Srivatsa wrote:
> Calculate the time that GuC takes to load using
> jiffies. This information could be very useful in
> determining if GuC is taking unreasonably long time
> to load in a certain platforms.
> 
> v2: Calculate time before logs are collected.
> Move the guc_load_time variable as a part of
> intel_uc_fw struct. Store only final result
> which is to be exported to debugfs. (Michal)
> Add the load time in the print message as well.
> 
> v3: Remove debugfs entry. Remove local variable
> guc_finish_load. (Daniel, Tvrtko)
> 
> v4: Use ktime_get() instead of jiffies. Use DRM_NOTE
> if time taken to load is more than the threshold. On
> load times within acceptable range, use DRM_DEBUG_DRIVER
> (Tvrtko)
> 
> v5: Rebased. Do not expose the load time variable in a global
> struct (Tvrtko, Joonas)

From my point of view (measuring suspend/resume times) knowing
how much time is spent loading GuC & HuC is really useful,
so it's definitely useful information.


Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check that the breadcrumb wasn't disarmed automatically before parking

[Joonas Lahtinen]

On Tue, 2017-10-31 at 12:22 +, Chris Wilson wrote:
> We will disarm the breadcrumb interrupt if we see a user interrupt
> whilst no one is waiting. This may race with the call to
> intel_engine_disarm_breadcrumbs() triggering an assert that we aren't
> trying to do the same job twice. Prevent this by checking that the irq
> is still armed after flushing the interrupt (for the irq spinlock).
> 
> Fixes: bcbd5c33a342 ("drm/i915/guc: Always enable the breadcrumbs irq")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michał Winiarski 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/huc: Add HuC Load time to dmesg log.

[Michal Wajdeczko]

On Wed, 01 Nov 2017 01:11:21 +0100, Anusha Srivatsa  
 wrote:



This patch uses jiffies to calculate the huc

  ^^^  ^^^
Please update commit message to match final change
and use correct name for HuC (s/huc/HuC)


load time.This information can be useful for testing
to know how much time huc takes to load.

v2: Remove debugfs entry. Remove local variable
huc_finish_load. (Daniel, Tvrtko)

v3: Use ktime_get() for more accurate timings.
Ensure the load is successful, before load times
is printed. (Tvrtko, Michal)

v4: Rebase. Do not expose the load time variable in a gobal
struct. Use int for load time (Tvrtko, Joonas)

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Michal Wajdeczko 
Cc: Oscar Mateo Lozano 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_huc.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c  
b/drivers/gpu/drm/i915/intel_huc.c

index 98d1725..3e3ce14 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -127,7 +127,8 @@ static int huc_ucode_xfer(struct intel_uc_fw  
*huc_fw, struct i915_vma *vma)

struct drm_i915_private *dev_priv = huc_to_i915(huc);
unsigned long offset = 0;
u32 size;
-   int ret;
+   int ret, load_time;
+   ktime_t start_load;
GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
@@ -148,13 +149,19 @@ static int huc_ucode_xfer(struct intel_uc_fw  
*huc_fw, struct i915_vma *vma)

I915_WRITE(DMA_COPY_SIZE, size);
/* Start the DMA */
+   start_load = ktime_get();
I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(HUC_UKERNEL | START_DMA));
/* Wait for DMA to finish */
 	ret = intel_wait_for_register_fw(dev_priv, DMA_CTRL, START_DMA, 0,  
100);

+   load_time = ktime_ms_delta(ktime_get(), start_load);
+
DRM_DEBUG_DRIVER("HuC DMA transfer wait over with ret %d\n", ret);
+   if (!ret)
+   DRM_DEBUG_DRIVER("HuC is loaded in %d ms\n", load_time);
+


Maybe we can squash above two messages into:

DRM_DEBUG_DRIVER("HuC DMA transfer %s in %dms\n",
 ret ? "timedout" ? "completed",
 load_time);


/* Disable the bits once DMA is over */
I915_WRITE(DMA_CTRL, _MASKED_BIT_DISABLE(HUC_UKERNEL));

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Add GuC Load time to dmesg log.

[Chris Wilson]

Quoting Michal Wajdeczko (2017-11-01 13:14:33)
> On Wed, 01 Nov 2017 01:11:20 +0100, Anusha Srivatsa  
> > @@ -172,13 +174,18 @@ static int guc_ucode_xfer_dma(struct  
> > drm_i915_private *dev_priv,
> >*/
> >   ret = wait_for(guc_ucode_response(dev_priv, ), 100);
> > + load_time = ktime_ms_delta(ktime_get(), start_load);
> > +
> >   DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
> >   I915_READ(DMA_CTRL), status);
> >   if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
> >   DRM_ERROR("GuC firmware signature verification failed\n");
> >   ret = -ENOEXEC;
> > - }
> > + } else if (load_time > 20)
> > + DRM_NOTE("GuC load takes more than acceptable threshold\n");
> 
> Please add threshold and actual load time to the message to let user
> know that times

The more important question is why are we telling the user this at all;
a significant but normal condition. What do we expect them to do? It
doesn't impair any functionality of the driver, it just took longer than
you expected -- which may be simply because the system was doing
something else and we slept for longer.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [resend] drm/i915: Check incoming alignment for unfenced buffers (on i915gm)

[Joonas Lahtinen]

On Tue, 2017-10-31 at 10:36 +, Chris Wilson wrote:
> In case the object has changed tiling between calls to execbuf, we need
> to check if the existing offset inside the GTT matches the new tiling
> constraint. We even need to do this for "unfenced" tiled objects, where
> the 3D commands use an implied fence and so the object still needs to
> match the physical fence restrictions on alignment (only required for
> gen2 and early gen3).
> 
> In commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over
> the execobjects array"), the idea was to remove the second guessing and
> only set the NEEDS_MAP flag when required. However, the entire check
> for an unusable offset for fencing was removed and not just the
> secondary check. I.e.
> 
>   /* avoid costly ping-pong once a batch bo ended up non-mappable */
> if (entry->flags & __EXEC_OBJECT_NEEDS_MAP &&
> !i915_vma_is_map_and_fenceable(vma))
> return !only_mappable_for_reloc(entry->flags);
> 
> was entirely removed as the ping-pong between execbuf passes was fixed,
> but its primary purpose in forcing unaligned unfenced access to be
> rebound was forgotten.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103502
> Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the 
> execobjects array")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx