[Intel-gfx] [PATCH v6] drm/i915: Tidy workaround batch buffer emission

2017-02-16 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Use the "*batch++ = " style as in the ring emission for better
readability and also simplify the logic a bit by consolidating
the offset and size calculations and overflow checking. The
latter is a programming error so it is not required to check
for it after each write to the object, but rather do it once the
whole state has been written and fail the driver if something
went wrong.

v2: Rebase.

v3: Keep track of offsets and sizes in bytes for simplicity
and rename function pointer variable to _fn suffix.
(Chris Wilson)

v4: Fix size calc broken in v3 and add alignment warning. (Chris Wilson)

v5: Fix return code.

v6: I added an exit from loop in v5 but forgot to put back
the object teardown.

Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson  (v5)
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 318 ++-
 1 file changed, 117 insertions(+), 201 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ee431d39ce06..5154661a38cf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -890,18 +890,6 @@ static int execlists_request_alloc(struct 
drm_i915_gem_request *request)
return ret;
 }
 
-#define wa_ctx_emit(batch, index, cmd) \
-   do {\
-   int __index = (index)++;\
-   if (WARN_ON(__index >= (PAGE_SIZE / sizeof(uint32_t { \
-   return -ENOSPC; \
-   }   \
-   batch[__index] = (cmd); \
-   } while (0)
-
-#define wa_ctx_emit_reg(batch, index, reg) \
-   wa_ctx_emit((batch), (index), i915_mmio_reg_offset(reg))
-
 /*
  * In this WA we need to set GEN8_L3SQCREG4[21:21] and reset it after
  * PIPE_CONTROL instruction. This is required for the flush to happen correctly
@@ -918,56 +906,31 @@ static int execlists_request_alloc(struct 
drm_i915_gem_request *request)
  * This WA is also required for Gen9 so extracting as a function avoids
  * code duplication.
  */
-static inline int gen8_emit_flush_coherentl3_wa(struct intel_engine_cs *engine,
-   uint32_t *batch,
-   uint32_t index)
-{
-   uint32_t l3sqc4_flush = (0x4040 | GEN8_LQSC_FLUSH_COHERENT_LINES);
-
-   wa_ctx_emit(batch, index, (MI_STORE_REGISTER_MEM_GEN8 |
-  MI_SRM_LRM_GLOBAL_GTT));
-   wa_ctx_emit_reg(batch, index, GEN8_L3SQCREG4);
-   wa_ctx_emit(batch, index, i915_ggtt_offset(engine->scratch) + 256);
-   wa_ctx_emit(batch, index, 0);
-
-   wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
-   wa_ctx_emit_reg(batch, index, GEN8_L3SQCREG4);
-   wa_ctx_emit(batch, index, l3sqc4_flush);
-
-   wa_ctx_emit(batch, index, GFX_OP_PIPE_CONTROL(6));
-   wa_ctx_emit(batch, index, (PIPE_CONTROL_CS_STALL |
-  PIPE_CONTROL_DC_FLUSH_ENABLE));
-   wa_ctx_emit(batch, index, 0);
-   wa_ctx_emit(batch, index, 0);
-   wa_ctx_emit(batch, index, 0);
-   wa_ctx_emit(batch, index, 0);
-
-   wa_ctx_emit(batch, index, (MI_LOAD_REGISTER_MEM_GEN8 |
-  MI_SRM_LRM_GLOBAL_GTT));
-   wa_ctx_emit_reg(batch, index, GEN8_L3SQCREG4);
-   wa_ctx_emit(batch, index, i915_ggtt_offset(engine->scratch) + 256);
-   wa_ctx_emit(batch, index, 0);
-
-   return index;
-}
-
-static inline uint32_t wa_ctx_start(struct i915_wa_ctx_bb *wa_ctx,
-   uint32_t offset,
-   uint32_t start_alignment)
+static u32 *
+gen8_emit_flush_coherentl3_wa(struct intel_engine_cs *engine, u32 *batch)
 {
-   return wa_ctx->offset = ALIGN(offset, start_alignment);
-}
-
-static inline int wa_ctx_end(struct i915_wa_ctx_bb *wa_ctx,
-uint32_t offset,
-uint32_t size_alignment)
-{
-   wa_ctx->size = offset - wa_ctx->offset;
-
-   WARN(wa_ctx->size % size_alignment,
-"wa_ctx_bb failed sanity checks: size %d is not aligned to %d\n",
-wa_ctx->size, size_alignment);
-   return 0;
+   *batch++ = MI_STORE_REGISTER_MEM_GEN8 | MI_SRM_LRM_GLOBAL_GTT;
+   *batch++ = i915_mmio_reg_offset(GEN8_L3SQCREG4);
+   *batch++ = i915_ggtt_offset(engine->scratch) + 256;
+   *batch++ = 0;
+
+   *batch++ = MI_LOAD_REGISTER_IMM(1);
+   *batch++ = i915_mmio_reg_offset(GEN8_L3SQCREG4);
+   *batch++ = 0x4040 | GEN8_LQSC_FLUSH_COHERENT_LINES;
+
+   *batch++ = GFX_OP_PIPE_CONTROL(6);
+   *batch++ = 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE PATCHES (rev5)

2017-02-16 Thread Chauhan, Madhav


> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, February 16, 2017 11:45 PM
> To: Chauhan, Madhav ; Patchwork
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE
> PATCHES (rev5)
> 
> On Thu, 16 Feb 2017, "Chauhan, Madhav" 
> wrote:
> >> -Original Message-
> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> >> Sent: Thursday, February 16, 2017 8:49 PM
> >> To: Patchwork ; Chauhan, Madhav
> >> 
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO
> >> MODE PATCHES (rev5)
> >>
> >> On Tue, 14 Feb 2017, Patchwork 
> >> wrote:
> >> > drivers/gpu/drm/i915/intel_dsi_pll.c: In function
> ‘intel_compute_dsi_pll’:
> >> > drivers/gpu/drm/i915/intel_dsi_pll.c:513:45: error: ‘dsi_ratio_max’
> >> > may be
> >> used uninitialized in this function [-Werror=maybe-uninitialized]
> >> >   if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
> >> >  ^
> >> > drivers/gpu/drm/i915/intel_dsi_pll.c:492:31: note: ‘dsi_ratio_max’
> >> > was
> >> declared here
> >> >   u8 dsi_ratio, dsi_ratio_min, dsi_ratio_max;
> >> >^
> >> >   LD  drivers/tty/serial/built-in.o
> >> >   LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
> >> > cc1: all warnings being treated as errors
> >> > scripts/Makefile.build:294: recipe for target
> >> > 'drivers/gpu/drm/i915/intel_dsi_pll.o' failed
> >> > make[4]: *** [drivers/gpu/drm/i915/intel_dsi_pll.o] Error 1
> >> > make[4]: *** Waiting for unfinished jobs
> >>
> >> The series didn't get tested because of this. Please update the
> >> series and repost, and do remember to add the Reviewed-by tags to the
> >> patches I've reviewed so far.
> >
> > Agree. Surprised to see why I didn’t get this error during compilation
> > in my local environment. Used x86_64_defconfig. Any idea ??
> 
> The CI usees DRM_I915_WERROR=y, among other debug config options.

I had enabled that option while testing but no warning/error. Looks like we 
need to
add  "maybe-uninitialized" to Werror lists or something else.

> 
> BR,
> Jani.
> 
> 
> >
> >>
> >> Thanks,
> >> Jani.
> >>
> >>
> >>
> >> --
> >> Jani Nikula, Intel Open Source Technology Center
> 
> --
> Jani Nikula, 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] [GLK MIPI DSI V5 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

2017-02-16 Thread Chauhan, Madhav
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, February 16, 2017 8:38 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Shankar, Uma ; Mukherjee, Indranil
> ; Saarinen, Jani ;
> Kamath, Sunil ; Deepak M
> ; Chauhan, Madhav 
> Subject: Re: [GLK MIPI DSI V5 3/8] drm/i915/glk: Add MIPIIO Enable/disable
> sequence
> 
> On Tue, 14 Feb 2017, Madhav Chauhan 
> wrote:
> > From: Deepak M 
> >
> > v2: Addressed Jani's Review comments(renamed bit field macros)
> > v3: Jani's Review comment for aligning code to platforms and added
> > wrapper functions.
> > v4: Corrected enable/disable seuqence as per BSPEC
> >
> > Signed-off-by: Deepak M 
> > Signed-off-by: Madhav Chauhan 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 206
> > ---
> >  1 file changed, 195 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 03d0999..a72a10f 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct
> intel_encoder *encoder,
> > return true;
> >  }
> >
> > +static void glk_dsi_device_ready(struct intel_encoder *encoder) {
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> > +   enum port port;
> > +   u32 tmp, val;
> > +
> > +   /* Set the MIPI mode
> > +* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
> > +* Power ON MIPI IO first and then write into IO reset and LP wake
> bits
> > +*/
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   tmp = I915_READ(MIPI_CTRL(port));
> > +   I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
> > +   }
> > +
> > +   /* Put the IO into reset */
> > +   tmp = I915_READ(MIPI_CTRL(PORT_A));
> > +   tmp &= ~GLK_MIPIIO_RESET_RELEASED;
> > +   I915_WRITE(MIPI_CTRL(PORT_A), tmp);
> > +
> > +   /* Program LP Wake */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   tmp = I915_READ(MIPI_CTRL(port));
> > +   tmp |= GLK_LP_WAKE;
> > +   I915_WRITE(MIPI_CTRL(port), tmp);
> > +   }
> > +
> > +   /* Wait for Pwr ACK */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   if (intel_wait_for_register(dev_priv,
> > +   MIPI_CTRL(port),
> GLK_MIPIIO_PORT_POWERED,
> > +   GLK_MIPIIO_PORT_POWERED, 20))
> > +   DRM_ERROR("Power ACK not received\n");
> > +   }
> > +
> > +   /* Wait for MIPI PHY status bit to set */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   if (intel_wait_for_register(dev_priv,
> > +   MIPI_CTRL(port),
> GLK_MIPIIO_PORT_POWERED,
> > +   GLK_MIPIIO_PORT_POWERED, 20))
> > +   DRM_ERROR("PHY is not ON\n");
> > +   }
> 
> You have the same wait twice here, with different comments and error
> messages.

Right. Second wait has to be done for PHY STATUS bit. Looks like it got messed 
up
when I renamed the bit definitions. Will correct it. Thanks for pointing out.

> 
> > +
> > +   /* Get IO out of reset */
> > +   tmp = I915_READ(MIPI_CTRL(PORT_A));
> > +   I915_WRITE(MIPI_CTRL(PORT_A), tmp |
> GLK_MIPIIO_RESET_RELEASED);
> > +
> > +   /* Get IO out of Low power state*/
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   if (!(I915_READ(MIPI_DEVICE_READY(port)) &
> DEVICE_READY)) {
> > +   val = I915_READ(MIPI_DEVICE_READY(port));
> > +   val &= ~ULPS_STATE_MASK;
> > +   val |= DEVICE_READY;
> > +   I915_WRITE(MIPI_DEVICE_READY(port), val);
> > +   usleep_range(10, 15);
> > +   }
> > +
> > +   /* Enter ULPS */
> > +   val = I915_READ(MIPI_DEVICE_READY(port));
> > +   val &= ~ULPS_STATE_MASK;
> > +   val |= (ULPS_STATE_ENTER | DEVICE_READY);
> > +   I915_WRITE(MIPI_DEVICE_READY(port), val);
> > +
> > +   /* Wait for ULPS Not active */
> > +   if (intel_wait_for_register(dev_priv,
> > +   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> > +   GLK_ULPS_NOT_ACTIVE, 20))
> > +
> > +   /* Exit ULPS */
> > +   val = I915_READ(MIPI_DEVICE_READY(port));
> > +   val &= ~ULPS_STATE_MASK;
> > +   val |= (ULPS_STATE_EXIT | DEVICE_READY);
> > +   I915_WRITE(MIPI_DEVICE_READY(port), val);
> > +
> > +   /* Enter Normal Mode */
> > +   val = 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DMC 1.03 for Geminilake (rev5)

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm/i915: DMC 1.03 for Geminilake (rev5)
URL   : https://patchwork.freedesktop.org/series/19081/
State : success

== Summary ==

Series 19081v5 drm/i915: DMC 1.03 for Geminilake
https://patchwork.freedesktop.org/api/1.0/series/19081/revisions/5/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

c2033e7aa383d062000e024c5fac5f46560327cd drm-tip: 2017y-02m-16d-20h-42m-04s UTC 
integration manifest
53bcf78 drm/i915: DMC 1.03 for Geminilake

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3869/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PULL] drm-misc-next-fixes, take 2

2017-02-16 Thread Dave Airlie
On 16 February 2017 at 19:49, Jani Nikula  wrote:
>
> Hi Dave, this one superseeds [1]. Better to flush out the single uapi
> fix for v4.11 now so it's not forgotten.

Looks like I had already pulled, I just reverted Maarten's patch on
top of drm-next.

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


[Intel-gfx] ✓ Fi.CI.BAT: success for i915/drm/HuC: Motivation behind having HuC (rev2)

2017-02-16 Thread Patchwork
== Series Details ==

Series: i915/drm/HuC: Motivation behind having HuC (rev2)
URL   : https://patchwork.freedesktop.org/series/19746/
State : success

== Summary ==

Series 19746v2 i915/drm/HuC: Motivation behind having HuC
https://patchwork.freedesktop.org/api/1.0/series/19746/revisions/2/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

c2033e7aa383d062000e024c5fac5f46560327cd drm-tip: 2017y-02m-16d-20h-42m-04s UTC 
integration manifest
cad5985 i915/drm/HuC: Motivation behind having HuC

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3868/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: DMC 1.03 for Geminilake

2017-02-16 Thread Rodrigo Vivi
There is a new version of DMC available for Geminilake.

It's release notes only mention:
- Enhancement in the FW to restore the PG2 state

v2: Fixed the platform name on commit message.
Noticed by Jani S.
v3: cook on top of drm-tip without depending on kbl
one so CI can check.
v4: make v3 on top of v2.

Cc: David Weinehall 
Cc: Jani Saarinen 
Cc: Ander Conselvan de Oliveira 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ander Conselvan de Oliveira 
Signed-off-by: Rodrigo Vivi 
---
 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 9dcc434..14659c7 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -34,9 +34,9 @@
  * low-power state and comes back to normal.
  */
 
-#define I915_CSR_GLK "i915/glk_dmc_ver1_01.bin"
+#define I915_CSR_GLK "i915/glk_dmc_ver1_03.bin"
 MODULE_FIRMWARE(I915_CSR_GLK);
-#define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 1)
+#define GLK_CSR_VERSION_REQUIRED   CSR_VERSION(1, 3)
 
 #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
 MODULE_FIRMWARE(I915_CSR_KBL);
-- 
1.9.1

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


[Intel-gfx] [PATCH] i915/drm/HuC: Motivation behind having HuC

2017-02-16 Thread Anusha Srivatsa
Correct the comment in intel_huc.c that tells the motivation
behind having HuC, a dedicated firmware for media.

Cc: Lyncoln Cheng 
Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_huc.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index c144609..0641afe 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -29,9 +29,14 @@
  * DOC: HuC Firmware
  *
  * Motivation:
- * GEN9 introduces a new dedicated firmware for usage in media HEVC (High
- * Efficiency Video Coding) operations. Userspace can use the firmware
- * capabilities by adding HuC specific commands to batch buffers.
+ *
+ * HuC is designed to offload some of the media functions from
+ * the CPU to GPU. These include but are not limited to bitrate
+ * control, header parsing. For example in the case of bitrate control,
+ * driver invokes HuC in the beginning of each frame encoding pass,
+ * encode bitrate is adjusted by the calculation done by HuC. Both
+ * the HuC hardware and the encode hardcode reside in GPU. Using HuC
+ * will save unnecessary CPU-GPU synchronization
  *
  * Implementation:
  * The same firmware loader is used as the GuC. However, the actual
-- 
2.7.4

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add DPCD definitions for DP 1.4 DSC feature (rev3)

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm: Add DPCD definitions for DP 1.4 DSC feature (rev3)
URL   : https://patchwork.freedesktop.org/series/19666/
State : success

== Summary ==

Series 19666v3 drm: Add DPCD definitions for DP 1.4 DSC feature
https://patchwork.freedesktop.org/api/1.0/series/19666/revisions/3/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

c2033e7aa383d062000e024c5fac5f46560327cd drm-tip: 2017y-02m-16d-20h-42m-04s UTC 
integration manifest
eb47d5f drm: Add DPCD definitions for DP 1.4 DSC feature

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3867/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm: Add DPCD definitions for DP 1.4 DSC feature

2017-02-16 Thread Manasi Navare
Display stream compression is supported on DP 1.4 DP
devices. This patch adds the corersponding DPCD
register definitions for DSC.

v2:
* Rebased on drm-tip

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Paulo Zanoni 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drm_dp_helper.h | 102 
 1 file changed, 102 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ba89295..4c1fc26 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -179,6 +179,108 @@
 
 #define DP_GUID0x030   /* 1.2 */
 
+#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
+# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
+
+#define DP_DSC_REV  0x061
+# define DP_DSC_MAJOR_MASK  (15 << 0)
+# define DP_DSC_MINOR_MASK  (15 << 4)
+# define DP_DSC_MINOR_SHIFT 4
+
+#define DP_DSC_RC_BUF_BLK_SIZE  0x062
+# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
+# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
+# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
+# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
+
+#define DP_DSC_RC_BUF_SIZE  0x063
+
+#define DP_DSC_SLICE_CAP_1  0x064
+# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
+# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
+# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
+# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
+# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
+# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
+# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
+
+#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
+# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (15 << 0)
+# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
+# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
+# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
+# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
+# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
+# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
+# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
+# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
+# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
+
+#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
+# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
+
+#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
+
+#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
+
+#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
+# define DP_DSC_RGB (1 << 0)
+# define DP_DSC_YCbCr444(1 << 1)
+# define DP_DSC_YCbCr422_Simple (1 << 2)
+# define DP_DSC_YCbCr422_Native (1 << 3)
+# define DP_DSC_YCbCr420_Native (1 << 4)
+
+#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
+# define DP_DSC_8_BPC   (1 << 1)
+# define DP_DSC_10_BPC  (1 << 2)
+# define DP_DSC_12_BPC  (1 >> 3)
+
+#define DP_DSC_PEAK_THROUGHPUT  0x06B
+# define DP_DSC_THROUGHPUT_MODE_0_340   0x1
+# define DP_DSC_THROUGHPUT_MODE_0_400   0x2
+# define DP_DSC_THROUGHPUT_MODE_0_450   0x3
+# define DP_DSC_THROUGHPUT_MODE_0_500   0x4
+# define DP_DSC_THROUGHPUT_MODE_0_550   0x5
+# define DP_DSC_THROUGHPUT_MODE_0_600   0x6
+# define DP_DSC_THROUGHPUT_MODE_0_650   0x7
+# define DP_DSC_THROUGHPUT_MODE_0_700   0x8
+# define DP_DSC_THROUGHPUT_MODE_0_750   0x9
+# define DP_DSC_THROUGHPUT_MODE_0_800   0xA
+# define DP_DSC_THROUGHPUT_MODE_0_850   0xB
+# define DP_DSC_THROUGHPUT_MODE_0_900   0xC
+# define DP_DSC_THROUGHPUT_MODE_0_950   0xD
+# define DP_DSC_THROUGHPUT_MODE_0_1000  0xE
+# define DP_DSC_THROUGHPUT_MODE_1_MASK  (15 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
+# define DP_DSC_THROUGHPUT_MODE_1_340   (1 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_400   (2 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_450   (3 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_500   (4 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_550   (5 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_600   (6 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_650   (7 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_700   (8 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_750   (9 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_800   (10 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_850   (11 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_900   (12 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_950   (13 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_1000  (14 << 4)
+
+#define DP_DSC_MAX_SLICE_WIDTH  0x06C
+
+#define DP_DSC_SLICE_CAP_2  0x06D
+# define DP_DSC_16_PER_DP_DSC_SINK  (1 << 0)
+# define DP_DSC_20_PER_DP_DSC_SINK  (1 << 1)
+# define DP_DSC_24_PER_DP_DSC_SINK  (1 << 2)
+

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

2017-02-16 Thread Chris Wilson
On Thu, Feb 16, 2017 at 06:15:05AM -0800, Oscar Mateo wrote:
>  static void guc_ctx_desc_init(struct intel_guc *guc,
> struct i915_guc_client *client)
>  {
>   struct drm_i915_private *dev_priv = guc_to_i915(guc);
>   struct intel_engine_cs *engine;
>   struct i915_gem_context *ctx = client->owner;
> - struct guc_context_desc desc;
> - struct sg_table *sg;
> + struct guc_context_desc *desc;
>   unsigned int tmp;
>   u32 gfx_addr;
>  
> - memset(, 0, sizeof(desc));
> + desc = __get_context_desc(client);

Do you want to make the assumption that these are zeroed-on-create
objects? We could switch to using non-swappable (internal) objects that
are not cleared on create. i.e.

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 4a752f2b6e24..4128e8937b45 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -650,7 +650,7 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
struct i915_vma *vma;
int ret;
 
-   obj = i915_gem_object_create(dev_priv, size);
+   obj = i915_gem_object_create_internal(dev_priv, size);
if (IS_ERR(obj))
return ERR_CAST(obj);
 
Or do we write the entire desc? It doesn't look like we do, but do we do
enough?

Other than that potential booby trap for later,
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t] tools/intel_guc_logger: Fix the assert for the verbosity level

2017-02-16 Thread Oscar Mateo
I guess no one has needed to change the verbosity level of the GuC logs.

Signed-off-by: Oscar Mateo 
---
 tools/intel_guc_logger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/intel_guc_logger.c b/tools/intel_guc_logger.c
index 159a54e..c9ea60d 100644
--- a/tools/intel_guc_logger.c
+++ b/tools/intel_guc_logger.c
@@ -302,7 +302,7 @@ static int parse_options(int opt, int opt_index, void *data)
switch(opt) {
case 'v':
verbosity_level = atoi(optarg);
-   igt_assert_f(verbosity_level < 0 || verbosity_level > 3, 
"invalid input for -v option\n");
+   igt_assert_f(verbosity_level >= 0 && verbosity_level <= 3, 
"invalid input for -v option\n");
igt_debug("verbosity level to be used is %d\n", 
verbosity_level);
break;
case 'o':
-- 
1.9.1

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: VLV/CHV two-stage watermarks (rev2)

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm/i915: VLV/CHV two-stage watermarks (rev2)
URL   : https://patchwork.freedesktop.org/series/16712/
State : success

== Summary ==

Series 16712v2 drm/i915: VLV/CHV two-stage watermarks
https://patchwork.freedesktop.org/api/1.0/series/16712/revisions/2/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

c2033e7aa383d062000e024c5fac5f46560327cd drm-tip: 2017y-02m-16d-20h-42m-04s UTC 
integration manifest
3075e09 drm/i915: Add FIFO underrun tracepoints
3f7fef8 drm/i915: Add cxsr toggle tracepoint
ef01cfb drm/i915: Add VLV/CHV watermark/FIFO programming tracepoints
027dcd2 drm/i915: Add plane update/disable tracepoints
540bda6 drm/i915: Kill level 0 wm hack for VLV/CHV
e888f80 drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun
53dd443 drm/i915: Sanitize VLV/CHV watermarks properly
1fa9864 drm/i915: Only use update_wm_{pre, post} for pre-ilk platforms
a5f675e drm/i915: Nuke crtc->wm.cxsr_allowed
58db269 drm/i915: Compute proper intermediate wms for vlv/cvh
3fb8e38 drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not 
needed
53ed9ee drm/i915: Compute vlv/chv wms the atomic way
f7a92c6 drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks
d76aa3c drm/i915: Plop vlv/chv fifo sizes into crtc state
5ce068a drm/i915: Plop vlv wm state into crtc_state
262b888 drm/i915: Move vlv wms from crtc->wm_state to crtc->wm.active.vlv
fe0354c drm/i915: Track plane fifo sizes under intel_crtc
56e8c1b drm/i915: Track visible planes in a bitmask

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3864/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/guc: Add onion teardown to the GuC setup

2017-02-16 Thread Oscar Mateo
This goes on top of "Keep the ctx_pool_vaddr mapped, for easy access", 
which is in turn goes on top of Joonas' "Sanitize GuC client 
initialization". If the reviews go well and once Joonas finishes his 
patch, I can resend everything as a series so that merging is easier.


-- Oscar

On 02/16/2017 06:18 AM, Oscar Mateo wrote:

Starting with intel_guc_loader, down to intel_guc_submission
and finally to intel_guc_log.

Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_guc_submission.c |  94 +
  drivers/gpu/drm/i915/intel_guc_loader.c|  19 +-
  drivers/gpu/drm/i915/intel_guc_log.c   | 309 +++--
  drivers/gpu/drm/i915/intel_uc.h|   5 +-
  4 files changed, 229 insertions(+), 198 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index f7d9897..4147674 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -609,8 +609,14 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
return vma;
  }
  
-static void guc_client_free(struct i915_guc_client *client)

+static void guc_client_free(struct i915_guc_client **p_client)
  {
+   struct i915_guc_client *client;
+
+   client = fetch_and_zero(p_client);
+   if (!client)
+   return;
+
/*
 * XXX: wait for any outstanding submissions before freeing memory.
 * Be sure to drop any locks
@@ -818,7 +824,7 @@ static void guc_policies_init(struct guc_policies *policies)
policies->is_valid = 1;
  }
  
-static void guc_addon_create(struct intel_guc *guc)

+static int guc_addon_create(struct intel_guc *guc)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct i915_vma *vma;
@@ -835,14 +841,11 @@ static void guc_addon_create(struct intel_guc *guc)
sizeof(struct guc_mmio_reg_state) +
GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE;
  
-	vma = guc->ads_vma;

-   if (!vma) {
-   vma = intel_guc_allocate_vma(guc, PAGE_ALIGN(size));
-   if (IS_ERR(vma))
-   return;
+   vma = intel_guc_allocate_vma(guc, PAGE_ALIGN(size));
+   if (IS_ERR(vma))
+   return PTR_ERR(vma);
  
-		guc->ads_vma = vma;

-   }
+   guc->ads_vma = vma;
  
  	page = i915_vma_first_page(vma);

ads = kmap(page);
@@ -885,6 +888,13 @@ static void guc_addon_create(struct intel_guc *guc)
sizeof(struct guc_mmio_reg_state);
  
  	kunmap(page);

+
+   return 0;
+}
+
+static void guc_addon_destroy(struct intel_guc *guc)
+{
+   i915_vma_unpin_and_release(>ads_vma);
  }
  
  /*

@@ -899,6 +909,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
struct intel_guc *guc = _priv->guc;
struct i915_vma *vma;
void *vaddr;
+   int ret;
  
  	if (!HAS_GUC_SCHED(dev_priv))

return 0;
@@ -919,15 +930,23 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
  
  	guc->ctx_pool = vma;
  
-	vaddr = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);

-   if (IS_ERR(vaddr))
-   goto err;
+   vaddr = i915_gem_object_pin_map(guc->ctx_pool->obj, I915_MAP_WB);
+   if (IS_ERR(vaddr)) {
+   ret = PTR_ERR(vaddr);
+   goto err_vma;
+   }
  
  	guc->ctx_pool_vaddr = vaddr;
  
+	ret = intel_guc_log_create(guc);

+   if (ret < 0)
+   goto err_vaddr;
+
+   ret = guc_addon_create(guc);
+   if (ret < 0)
+   goto err_log;
+
ida_init(>ctx_ids);
-   intel_guc_log_create(guc);
-   guc_addon_create(guc);
  
  	guc->execbuf_client = guc_client_alloc(dev_priv,

   INTEL_INFO(dev_priv)->ring_mask,
@@ -935,14 +954,33 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
   dev_priv->kernel_context);
if (IS_ERR(guc->execbuf_client)) {
DRM_ERROR("Failed to create GuC client for execbuf!\n");
-   goto err;
+   ret = PTR_ERR(guc->execbuf_client);
+   goto err_ads;
}
  
  	return 0;

+err_ads:
+   guc_addon_destroy(guc);
+err_log:
+   intel_guc_log_destroy(guc);
+err_vaddr:
+   i915_gem_object_unpin_map(guc->ctx_pool->obj);
+err_vma:
+   i915_vma_unpin_and_release(>ctx_pool);
  
-err:

-   i915_guc_submission_fini(dev_priv);
-   return -ENOMEM;
+   return ret;
+}
+
+void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+
+   guc_client_free(>execbuf_client);
+   ida_destroy(>ctx_ids);
+   guc_addon_destroy(guc);
+   intel_guc_log_destroy(guc);
+   i915_gem_object_unpin_map(guc->ctx_pool->obj);
+   i915_vma_unpin_and_release(>ctx_pool);
  }
  
  static void 

[Intel-gfx] [PATCH] drm/i915/guc: Add onion teardown to the GuC setup

2017-02-16 Thread Oscar Mateo
Starting with intel_guc_loader, down to intel_guc_submission
and finally to intel_guc_log.

Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_guc_submission.c |  94 +
 drivers/gpu/drm/i915/intel_guc_loader.c|  19 +-
 drivers/gpu/drm/i915/intel_guc_log.c   | 309 +++--
 drivers/gpu/drm/i915/intel_uc.h|   5 +-
 4 files changed, 229 insertions(+), 198 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index f7d9897..4147674 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -609,8 +609,14 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc 
*guc, u32 size)
return vma;
 }
 
-static void guc_client_free(struct i915_guc_client *client)
+static void guc_client_free(struct i915_guc_client **p_client)
 {
+   struct i915_guc_client *client;
+
+   client = fetch_and_zero(p_client);
+   if (!client)
+   return;
+
/*
 * XXX: wait for any outstanding submissions before freeing memory.
 * Be sure to drop any locks
@@ -818,7 +824,7 @@ static void guc_policies_init(struct guc_policies *policies)
policies->is_valid = 1;
 }
 
-static void guc_addon_create(struct intel_guc *guc)
+static int guc_addon_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct i915_vma *vma;
@@ -835,14 +841,11 @@ static void guc_addon_create(struct intel_guc *guc)
sizeof(struct guc_mmio_reg_state) +
GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE;
 
-   vma = guc->ads_vma;
-   if (!vma) {
-   vma = intel_guc_allocate_vma(guc, PAGE_ALIGN(size));
-   if (IS_ERR(vma))
-   return;
+   vma = intel_guc_allocate_vma(guc, PAGE_ALIGN(size));
+   if (IS_ERR(vma))
+   return PTR_ERR(vma);
 
-   guc->ads_vma = vma;
-   }
+   guc->ads_vma = vma;
 
page = i915_vma_first_page(vma);
ads = kmap(page);
@@ -885,6 +888,13 @@ static void guc_addon_create(struct intel_guc *guc)
sizeof(struct guc_mmio_reg_state);
 
kunmap(page);
+
+   return 0;
+}
+
+static void guc_addon_destroy(struct intel_guc *guc)
+{
+   i915_vma_unpin_and_release(>ads_vma);
 }
 
 /*
@@ -899,6 +909,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
struct intel_guc *guc = _priv->guc;
struct i915_vma *vma;
void *vaddr;
+   int ret;
 
if (!HAS_GUC_SCHED(dev_priv))
return 0;
@@ -919,15 +930,23 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
 
guc->ctx_pool = vma;
 
-   vaddr = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);
-   if (IS_ERR(vaddr))
-   goto err;
+   vaddr = i915_gem_object_pin_map(guc->ctx_pool->obj, I915_MAP_WB);
+   if (IS_ERR(vaddr)) {
+   ret = PTR_ERR(vaddr);
+   goto err_vma;
+   }
 
guc->ctx_pool_vaddr = vaddr;
 
+   ret = intel_guc_log_create(guc);
+   if (ret < 0)
+   goto err_vaddr;
+
+   ret = guc_addon_create(guc);
+   if (ret < 0)
+   goto err_log;
+
ida_init(>ctx_ids);
-   intel_guc_log_create(guc);
-   guc_addon_create(guc);
 
guc->execbuf_client = guc_client_alloc(dev_priv,
   INTEL_INFO(dev_priv)->ring_mask,
@@ -935,14 +954,33 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
   dev_priv->kernel_context);
if (IS_ERR(guc->execbuf_client)) {
DRM_ERROR("Failed to create GuC client for execbuf!\n");
-   goto err;
+   ret = PTR_ERR(guc->execbuf_client);
+   goto err_ads;
}
 
return 0;
+err_ads:
+   guc_addon_destroy(guc);
+err_log:
+   intel_guc_log_destroy(guc);
+err_vaddr:
+   i915_gem_object_unpin_map(guc->ctx_pool->obj);
+err_vma:
+   i915_vma_unpin_and_release(>ctx_pool);
 
-err:
-   i915_guc_submission_fini(dev_priv);
-   return -ENOMEM;
+   return ret;
+}
+
+void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+
+   guc_client_free(>execbuf_client);
+   ida_destroy(>ctx_ids);
+   guc_addon_destroy(guc);
+   intel_guc_log_destroy(guc);
+   i915_gem_object_unpin_map(guc->ctx_pool->obj);
+   i915_vma_unpin_and_release(>ctx_pool);
 }
 
 static void guc_reset_wq(struct i915_guc_client *client)
@@ -1004,26 +1042,6 @@ void i915_guc_submission_disable(struct drm_i915_private 
*dev_priv)
intel_execlists_enable_submission(dev_priv);
 }
 
-void i915_guc_submission_fini(struct drm_i915_private *dev_priv)
-{
-   struct intel_guc *guc = _priv->guc;
- 

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

2017-02-16 Thread Oscar Mateo

Onion teardown in a separate patch (since it addresses a separate problem).


On 02/16/2017 06:15 AM, Oscar Mateo wrote:

The GuC descriptor is big in size. If we use a local definition of
guc_desc we have a chance to overflow stack, so avoid it.

Also, Chris abhors scatterlists :)

v2: Rebased, helper function to retrieve the context descriptor,
s/ctx_pool_vma/ctx_pool/

Signed-off-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 94 ++
  drivers/gpu/drm/i915/intel_guc_loader.c|  2 +-
  drivers/gpu/drm/i915/intel_uc.h|  3 +-
  3 files changed, 48 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 3ea2c71..f7d9897 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -134,6 +134,12 @@ static int __guc_deallocate_doorbell(struct intel_guc 
*guc, u32 ctx_index)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
  }
  
+static struct guc_context_desc *__get_context_desc(struct i915_guc_client *client)

+{
+   return client->guc->ctx_pool_vaddr +
+   sizeof(struct guc_context_desc) * client->ctx_index;
+}
+
  /*
   * Initialise, update, or clear doorbell data shared with the GuC
   *
@@ -143,21 +149,11 @@ static int __guc_deallocate_doorbell(struct intel_guc 
*guc, u32 ctx_index)
  
  static int __update_doorbell_desc(struct i915_guc_client *client, u16 new_id)

  {
-   struct sg_table *sg = client->guc->ctx_pool_vma->pages;
-   struct guc_context_desc desc;
-   size_t len;
+   struct guc_context_desc *desc;
  
  	/* Update the GuC's idea of the doorbell ID */

-   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
-sizeof(desc) * client->ctx_index);
-   if (len != sizeof(desc))
-   return -EFAULT;
-
-   desc.db_id = new_id;
-   len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
-  sizeof(desc) * client->ctx_index);
-   if (len != sizeof(desc))
-   return -EFAULT;
+   desc = __get_context_desc(client);
+   desc->db_id = new_id;
  
  	return 0;

  }
@@ -270,29 +266,27 @@ static void guc_proc_desc_init(struct intel_guc *guc,
   * data structures relating to this client (doorbell, process descriptor,
   * write queue, etc).
   */
-
  static void guc_ctx_desc_init(struct intel_guc *guc,
  struct i915_guc_client *client)
  {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct intel_engine_cs *engine;
struct i915_gem_context *ctx = client->owner;
-   struct guc_context_desc desc;
-   struct sg_table *sg;
+   struct guc_context_desc *desc;
unsigned int tmp;
u32 gfx_addr;
  
-	memset(, 0, sizeof(desc));

+   desc = __get_context_desc(client);
  
-	desc.attribute = GUC_CTX_DESC_ATTR_ACTIVE | GUC_CTX_DESC_ATTR_KERNEL;

-   desc.context_id = client->ctx_index;
-   desc.priority = client->priority;
-   desc.db_id = client->doorbell_id;
+   desc->attribute = GUC_CTX_DESC_ATTR_ACTIVE | GUC_CTX_DESC_ATTR_KERNEL;
+   desc->context_id = client->ctx_index;
+   desc->priority = client->priority;
+   desc->db_id = client->doorbell_id;
  
  	for_each_engine_masked(engine, dev_priv, client->engines, tmp) {

struct intel_context *ce = >engine[engine->id];
uint32_t guc_engine_id = engine->guc_id;
-   struct guc_execlist_context *lrc = [guc_engine_id];
+   struct guc_execlist_context *lrc = >lrc[guc_engine_id];
  
  		/* TODO: We have a design issue to be solved here. Only when we

 * receive the first batch, we know which engine is used by the
@@ -317,50 +311,41 @@ static void guc_ctx_desc_init(struct intel_guc *guc,
lrc->ring_next_free_location = lrc->ring_begin;
lrc->ring_current_tail_pointer_value = 0;
  
-		desc.engines_used |= (1 << guc_engine_id);

+   desc->engines_used |= (1 << guc_engine_id);
}
  
  	DRM_DEBUG_DRIVER("Host engines 0x%x => GuC engines used 0x%x\n",

-   client->engines, desc.engines_used);
-   WARN_ON(desc.engines_used == 0);
+   client->engines, desc->engines_used);
+   WARN_ON(desc->engines_used == 0);
  
  	/*

 * The doorbell, process descriptor, and workqueue are all parts
 * of the client object, which the GuC will reference via the GGTT
 */
gfx_addr = guc_ggtt_offset(client->vma);
-   desc.db_trigger_phy = sg_dma_address(client->vma->pages->sgl) +
+   desc->db_trigger_phy = sg_dma_address(client->vma->pages->sgl) +
+   client->doorbell_offset;
+   desc->db_trigger_cpu = (uintptr_t)client->vaddr +

[Intel-gfx] [PATCH v2] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

2017-02-16 Thread Oscar Mateo
The GuC descriptor is big in size. If we use a local definition of
guc_desc we have a chance to overflow stack, so avoid it.

Also, Chris abhors scatterlists :)

v2: Rebased, helper function to retrieve the context descriptor,
s/ctx_pool_vma/ctx_pool/

Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 94 ++
 drivers/gpu/drm/i915/intel_guc_loader.c|  2 +-
 drivers/gpu/drm/i915/intel_uc.h|  3 +-
 3 files changed, 48 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 3ea2c71..f7d9897 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -134,6 +134,12 @@ static int __guc_deallocate_doorbell(struct intel_guc 
*guc, u32 ctx_index)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
 
+static struct guc_context_desc *__get_context_desc(struct i915_guc_client 
*client)
+{
+   return client->guc->ctx_pool_vaddr +
+   sizeof(struct guc_context_desc) * client->ctx_index;
+}
+
 /*
  * Initialise, update, or clear doorbell data shared with the GuC
  *
@@ -143,21 +149,11 @@ static int __guc_deallocate_doorbell(struct intel_guc 
*guc, u32 ctx_index)
 
 static int __update_doorbell_desc(struct i915_guc_client *client, u16 new_id)
 {
-   struct sg_table *sg = client->guc->ctx_pool_vma->pages;
-   struct guc_context_desc desc;
-   size_t len;
+   struct guc_context_desc *desc;
 
/* Update the GuC's idea of the doorbell ID */
-   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
-sizeof(desc) * client->ctx_index);
-   if (len != sizeof(desc))
-   return -EFAULT;
-
-   desc.db_id = new_id;
-   len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
-  sizeof(desc) * client->ctx_index);
-   if (len != sizeof(desc))
-   return -EFAULT;
+   desc = __get_context_desc(client);
+   desc->db_id = new_id;
 
return 0;
 }
@@ -270,29 +266,27 @@ static void guc_proc_desc_init(struct intel_guc *guc,
  * data structures relating to this client (doorbell, process descriptor,
  * write queue, etc).
  */
-
 static void guc_ctx_desc_init(struct intel_guc *guc,
  struct i915_guc_client *client)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct intel_engine_cs *engine;
struct i915_gem_context *ctx = client->owner;
-   struct guc_context_desc desc;
-   struct sg_table *sg;
+   struct guc_context_desc *desc;
unsigned int tmp;
u32 gfx_addr;
 
-   memset(, 0, sizeof(desc));
+   desc = __get_context_desc(client);
 
-   desc.attribute = GUC_CTX_DESC_ATTR_ACTIVE | GUC_CTX_DESC_ATTR_KERNEL;
-   desc.context_id = client->ctx_index;
-   desc.priority = client->priority;
-   desc.db_id = client->doorbell_id;
+   desc->attribute = GUC_CTX_DESC_ATTR_ACTIVE | GUC_CTX_DESC_ATTR_KERNEL;
+   desc->context_id = client->ctx_index;
+   desc->priority = client->priority;
+   desc->db_id = client->doorbell_id;
 
for_each_engine_masked(engine, dev_priv, client->engines, tmp) {
struct intel_context *ce = >engine[engine->id];
uint32_t guc_engine_id = engine->guc_id;
-   struct guc_execlist_context *lrc = [guc_engine_id];
+   struct guc_execlist_context *lrc = >lrc[guc_engine_id];
 
/* TODO: We have a design issue to be solved here. Only when we
 * receive the first batch, we know which engine is used by the
@@ -317,50 +311,41 @@ static void guc_ctx_desc_init(struct intel_guc *guc,
lrc->ring_next_free_location = lrc->ring_begin;
lrc->ring_current_tail_pointer_value = 0;
 
-   desc.engines_used |= (1 << guc_engine_id);
+   desc->engines_used |= (1 << guc_engine_id);
}
 
DRM_DEBUG_DRIVER("Host engines 0x%x => GuC engines used 0x%x\n",
-   client->engines, desc.engines_used);
-   WARN_ON(desc.engines_used == 0);
+   client->engines, desc->engines_used);
+   WARN_ON(desc->engines_used == 0);
 
/*
 * The doorbell, process descriptor, and workqueue are all parts
 * of the client object, which the GuC will reference via the GGTT
 */
gfx_addr = guc_ggtt_offset(client->vma);
-   desc.db_trigger_phy = sg_dma_address(client->vma->pages->sgl) +
+   desc->db_trigger_phy = sg_dma_address(client->vma->pages->sgl) +
+   client->doorbell_offset;
+   desc->db_trigger_cpu = (uintptr_t)client->vaddr +
client->doorbell_offset;
-   desc.db_trigger_cpu =
-   (uintptr_t)client->vaddr + 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Remove struct_mutex for destroying framebuffers (rev2)

2017-02-16 Thread Chris Wilson
On Thu, Feb 16, 2017 at 02:21:55PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2] drm/i915: Remove struct_mutex for 
> destroying framebuffers (rev2)
> URL   : https://patchwork.freedesktop.org/series/19692/
> State : success
> 
> == Summary ==
> 
> Series 19692v2 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/19692/revisions/2/mbox/
> 
> fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
> fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 
> 
> 89a932d98b6e1733011019c9872583a9c7c8fda3 drm-tip: 2017y-02m-16d-10h-06m-42s 
> UTC integration manifest
> b17bccf drm/i915: Drop struct_mutex around frontbuffer flushes
> 9dde3cf drm/i915: struct_mutex is not required for allocating the framebuffer
> 7e17535 drm/i915: Remove struct_mutex for destroying framebuffers

Thanks for the review, pushed. 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] i915/drm/HuC: Motivation behind having HuC

2017-02-16 Thread Rodrigo Vivi
This matches the description we got for release so,
Reviewed-by: Rodrigo Vivi 

On Wed, Feb 15, 2017 at 5:29 PM, Anusha Srivatsa
 wrote:
> Correct the comment in intel_huc.c that tells the motivation
> behind having HuC, a dedicated firmware for media.
>
> Cc: Lyncoln Cheng 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_huc.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_huc.c 
> b/drivers/gpu/drm/i915/intel_huc.c
> index c144609..0641afe 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -29,9 +29,14 @@
>   * DOC: HuC Firmware
>   *
>   * Motivation:
> - * GEN9 introduces a new dedicated firmware for usage in media HEVC (High
> - * Efficiency Video Coding) operations. Userspace can use the firmware
> - * capabilities by adding HuC specific commands to batch buffers.
> + *
> + * HuC is designed to offload some of the media functions from
> + * the CPU to GPU. These include but are not limited to bitrate
> + * control, header parsing. For example in the case of bitrate control,
> + * driver invokes HuC in the beginning of each frame encoding pass,
> + * encode bitrate is adjusted by the calculation done by HuC. Both
> + * the HuC hardware and the encode hardcode reside in GPU. Using HuC
> + * will save unnecessary CPU-GPU synchronization
>   *
>   * Implementation:
>   * The same firmware loader is used as the GuC. However, the actual
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl

2017-02-16 Thread Chris Wilson
On Thu, Feb 16, 2017 at 03:42:20PM +0200, Joonas Lahtinen wrote:
> On to, 2017-02-16 at 12:54 +, Chris Wilson wrote:
> > We wait upon jiffies, but report the time elapsed using a
> > high-resolution timer. This discrepancy can lead to us timing out the
> > wait prior to us reporting the elapsed time as complete.
> > 
> > This restores the squelching lost in commit e95433c73a11 ("drm/i915:
> > Rearrange i915_wait_request() accounting with callers").
> > 
> > Fixes: e95433c73a11 ("drm/i915: Rearrange i915_wait_request() accounting 
> > with callers")
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > Cc:  # v4.10-rc1+
> > Cc: sta...@vger.kernel.org
> 
> Reviewed-by: Joonas Lahtinen 

Thanks, pushed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
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 [v2] drm/i915: Take forcewake for setting the RPS thresholds (rev2)

2017-02-16 Thread Patchwork
== Series Details ==

Series: series starting with [v2] drm/i915: Take forcewake for setting the RPS 
thresholds (rev2)
URL   : https://patchwork.freedesktop.org/series/19794/
State : failure

== Summary ==

Series 19794v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/19794/revisions/2/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> INCOMPLETE (fi-snb-2600)

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:48   pass:38   dwarn:0   dfail:0   fail:0   skip:9  

b29710e319e4b58d994065f5e776f6f66674d7c9 drm-tip: 2017y-02m-16d-15h-35m-40s UTC 
integration manifest
361c046 drm/i915: Restart RPS using the same RP_CONTROL as from initialisation
774220d drm/i915: Take forcewake for setting the RPS thresholds

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3863/
___
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: Defer declaration of missed-interrupt until the waiter is asleep

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm/i915: Defer declaration of missed-interrupt until the waiter is 
asleep
URL   : https://patchwork.freedesktop.org/series/19791/
State : failure

== Summary ==

  CC [M]  drivers/gpu/drm/i915/gvt/cfg_space.o
  CC [M]  drivers/gpu/drm/i915/gvt/opregion.o
  CC [M]  drivers/gpu/drm/i915/gvt/display.o
  CC [M]  drivers/gpu/drm/i915/gvt/mmio.o
  CC [M]  drivers/gpu/drm/i915/gvt/edid.o
  LD [M]  drivers/gpu/drm/vgem/vgem.o
  CC [M]  drivers/gpu/drm/i915/gvt/execlist.o
  CC [M]  drivers/gpu/drm/i915/gvt/scheduler.o
  CC [M]  drivers/gpu/drm/i915/gvt/sched_policy.o
  CC [M]  drivers/gpu/drm/i915/gvt/render.o
  CC [M]  drivers/gpu/drm/i915/gvt/cmd_parser.o
  CC [M]  drivers/gpu/drm/i915/intel_lpe_audio.o
  LD  kernel/built-in.o
  LD  drivers/acpi/acpica/acpi.o
  LD [M]  fs/cifs/cifs.o
  LD  drivers/thermal/thermal_sys.o
  LD  drivers/thermal/built-in.o
  LD  drivers/acpi/acpica/built-in.o
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
  LD  sound/pci/built-in.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/storage/built-in.o
  LD  drivers/acpi/built-in.o
  LD  drivers/gpu/drm/drm.o
  LD  sound/built-in.o
  LD  drivers/scsi/scsi_mod.o
  LD  drivers/spi/built-in.o
  LD  drivers/video/fbdev/core/fb.o
  LD  drivers/tty/serial/8250/8250.o
  LD  drivers/video/fbdev/core/built-in.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/video/console/built-in.o
  LD  drivers/video/built-in.o
drivers/gpu/drm/i915/intel_breadcrumbs.c: In function 
‘intel_breadcrumbs_hangcheck’:
drivers/gpu/drm/i915/intel_breadcrumbs.c:47:28: error: implicit declaration of 
function ‘wait_timeout’ [-Werror=implicit-function-declaration]
   mod_timer(>hangcheck, wait_timeout());
^
drivers/gpu/drm/i915/intel_breadcrumbs.c: At top level:
drivers/gpu/drm/i915/intel_breadcrumbs.c:67:22: error: conflicting types for 
‘wait_timeout’
 static unsigned long wait_timeout(void)
  ^
drivers/gpu/drm/i915/intel_breadcrumbs.c:47:28: note: previous implicit 
declaration of ‘wait_timeout’ was here
   mod_timer(>hangcheck, wait_timeout());
^
  LD  drivers/pci/built-in.o
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/intel_breadcrumbs.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_breadcrumbs.o] Error 1
make[4]: *** Waiting for unfinished jobs
  LD  drivers/iommu/built-in.o
  LD  drivers/usb/gadget/libcomposite.o
  LD  net/ipv6/ipv6.o
  AR  lib/lib.a
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  EXPORTS lib/lib-ksyms.o
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  lib/built-in.o
  LD  net/ipv6/built-in.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/scsi/built-in.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  drivers/usb/gadget/built-in.o
  LD  drivers/tty/serial/built-in.o
  LD  fs/btrfs/btrfs.o
  LD  drivers/md/md-mod.o
  LD  drivers/md/built-in.o
  LD  drivers/usb/core/usbcore.o
  CC  arch/x86/kernel/cpu/capflags.o
  LD  drivers/usb/core/built-in.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  fs/btrfs/built-in.o
  LD  arch/x86/kernel/built-in.o
  LD  net/core/built-in.o
  LD  arch/x86/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/tty/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  net/ipv4/built-in.o
  LD  net/built-in.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  fs/ext4/ext4.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:988: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix DisplayPort Hotplug (rev2)

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix DisplayPort Hotplug (rev2)
URL   : https://patchwork.freedesktop.org/series/19601/
State : success

== Summary ==

Series 19601v2 drm/i915: Fix DisplayPort Hotplug
https://patchwork.freedesktop.org/api/1.0/series/19601/revisions/2/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

b29710e319e4b58d994065f5e776f6f66674d7c9 drm-tip: 2017y-02m-16d-15h-35m-40s UTC 
integration manifest
e8365fc drm/i915: Perform link quality check unconditionally during long pulse

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3861/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t v3] gitignore: Add files starting with .

2017-02-16 Thread Michel Thierry
I cant be the only one that have added .tags by mistake.

v2: Do not ignore .gitignore
v3: Move !.gitignore at the end, otherwise it'll ignore new .gitignore
files in another directory (Petri)

Cc: Petri Latvala 
Cc: Joonas Lahtinen 
Signed-off-by: Michel Thierry 
---
 .gitignore | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/.gitignore b/.gitignore
index 6204965a..de79020f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -81,6 +81,7 @@ core
 *.swo
 *.swp
 *.dirstamp
+.*
 cscope.*
 TAGS
 build-aux/
@@ -93,3 +94,8 @@ intel-gpu-tools-*/
 
 piglit
 results
+
+#
+# git files that we don't want to ignore even it they are dot-files
+#
+!.gitignore
-- 
2.11.0

___
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/atomic: Add accessor macros for all atomic state. (rev5)

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm/atomic: Add accessor macros for all atomic state. (rev5)
URL   : https://patchwork.freedesktop.org/series/17745/
State : success

== Summary ==

Series 17745v5 drm/atomic: Add accessor macros for all atomic state.
https://patchwork.freedesktop.org/api/1.0/series/17745/revisions/5/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

b29710e319e4b58d994065f5e776f6f66674d7c9 drm-tip: 2017y-02m-16d-15h-35m-40s UTC 
integration manifest
7df9cb5 drm/blend: Use new atomic iterator macros.
7e55380 drm/atomic: Convert get_existing_state callers to get_old/new_state, v3.
2be25d3 drm/atomic: Add macros to access existing old/new state, v2.
c3cbb76 drm/atomic: Make drm_atomic_plane_disabling easier to understand.
2024186 drm/atomic: Fix atomic helpers to use the new iterator macros, v2.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3860/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 08:59:13PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > On Thu, Feb 16, 2017 at 07:54:00PM +0200, Jani Nikula wrote:
> >> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> >> > On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
> >> >> Handle debugfs override edid and firmware edid at the low level to
> >> >> transparently and completely replace the real edid. Previously, we
> >> >> practically only used the modes from the override EDID, and none of the
> >> >> other data. This also prevents actual EDID reads when the EDID is to be
> >> >> overridden, but retains the DDC probe.
> >> >
> >> > Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
> >> > somethign then the override EDID wouldn't be returned by drm_get_edid().
> >> 
> >> Isn't this in line with how this currently works?
> >
> > Not really. If connector->force is used and an override EDID is
> > provided, then drm_get_edid() likely never gets called, and the modes
> > come directly from the overide EDID. With your change forcing the
> > connector state wouldn't because we still wouldn't get any modes
> > from the override EDID due to the DDC check.
> 
> Right.
> 
> > I guess one way around this would be to skip the DDC check if the
> > connector state has been forced.
> 
> I guess I'm asking if you think the whole approach here is
> workable. What we currently have is so flaky.

I'm 100% with you on that. So yes, I do like the idea.

I think the last time the override EDIDs were discussed someone was
suggesting that the EDID override itself should force the connector
state. IIRC Daniel didn't agree. I don't have a particularly strong
opinion either way, but I guess trying to preserve the current
semantics (ie. EDID override and connector status forcing are mostly
separate) would be the thing to aim for, at least initially.

> 
> BR,
> Jani.
> 
> >
> >> 
> >> BR,
> >> Jani.
> >> 
> >> 
> >> >
> >> >> 
> >> >> FIXME: validate override edid, deduplicate firmware edid validation.
> >> >> 
> >> >> Signed-off-by: Jani Nikula 
> >> >> ---
> >> >>  drivers/gpu/drm/drm_edid.c | 15 +++
> >> >>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> >> >>  2 files changed, 16 insertions(+), 18 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> >> index 362036360724..054e2d74eafc 100644
> >> >> --- a/drivers/gpu/drm/drm_edid.c
> >> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> >> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct 
> >> >> drm_connector *connector,
> >> >>   * level, drivers must make all reasonable efforts to expose it as an 
> >> >> I2C
> >> >>   * adapter and use drm_get_edid() instead of abusing this function.
> >> >>   *
> >> >> + * The EDID may be overridden using debugfs override_edid or firmare 
> >> >> EDID
> >> >> + * (drm_load_edid_firmware()), in this priority order. Having either 
> >> >> of them
> >> >> + * bypasses actual EDID reads.
> >> >> + *
> >> >>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> >> >>   */
> >> >>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> >> >> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct 
> >> >> drm_connector *connector,
> >> >>  {
> >> >> int i, j = 0, valid_extensions = 0;
> >> >> u8 *edid, *new;
> >> >> +   struct edid *override = NULL;
> >> >> +
> >> >> +   if (connector->override_edid)
> >> >> +   override = drm_edid_duplicate((const struct edid *)
> >> >> + 
> >> >> connector->edid_blob_ptr->data);
> >> >> +
> >> >> +   if (!override)
> >> >> +   override = drm_load_edid_firmware(connector);
> >> >> +
> >> >> +   if (!IS_ERR_OR_NULL(override))
> >> >> +   return override;
> >> >>  
> >> >> if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> >> >> return NULL;
> >> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> >> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> >> index 358957118ca9..871326cbc465 100644
> >> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> >> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector 
> >> >> *connector, bool force)
> >> >>   *drm_mode_probed_add(). New modes start their life with status as 
> >> >> OK.
> >> >>   *Modes are added from a single source using the following 
> >> >> priority order.
> >> >>   *
> >> >> - *- debugfs 'override_edid' (used for testing only)
> >> >> - *- firmware EDID (drm_load_edid_firmware())
> >> >>   *- _connector_helper_funcs.get_modes vfunc
> >> >>   *- if the connector status is connector_status_connected, standard
> >> >>   *  VESA DMT modes up to 1024x768 are automatically added
> >> >> @@ -305,22 +303,7 @@ 

Re: [Intel-gfx] [PATCH] lib/igt_kms: Fix regression on kms_plane_lowres test

2017-02-16 Thread Robert Foss

Applied and tested patch.

Reviewed-by: Robert Foss 

On 2017-02-16 09:06 AM, Mika Kahola wrote:

kms_plane_lowres subtest pipe-C-tiling-none crashes when reading out
number of crtc. This patch fixes the bug on crtc readout.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99653
Fixes: 9de635976c426b4c835083792c7d4d6e32aec615
   ("lib/igt_kms: Avoid depencency on static plane count")

Signed-off-by: Mika Kahola 
---
 lib/igt_kms.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index dae8bf9..5388a83 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1331,6 +1331,7 @@ void kmstest_get_crtc(enum pipe pipe, struct kmstest_crtc 
*crtc)
const char *mode = "r";
int ncrtc;
int line;
+   long int n;

fid = igt_debugfs_fopen("i915_display_info", mode);

@@ -1344,18 +1342,20 @@ void kmstest_get_crtc(enum pipe pipe, struct 
kmstest_crtc *crtc)
crtc->active = true;
parse_crtc(tmp, crtc);

+   n = ftell(fid);
crtc->n_planes = parse_planes(fid, NULL);
crtc->planes = calloc(crtc->n_planes, 
sizeof(*crtc->planes));
igt_assert_f(crtc->planes, "Failed to allocate memory 
for %d planes\n", crtc->n_planes);

-   fseek(fid, 0, SEEK_END);
-   fseek(fid, 0, SEEK_SET);
+   fseek(fid, n, SEEK_SET);
parse_planes(fid, crtc->planes);

-   if (crtc->pipe != pipe)
-   crtc = NULL;
-   else
+   if (crtc->pipe != pipe) {
+   free(crtc->planes);
+   } else {
ncrtc++;
+   break;
+   }
}
}



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


Re: [Intel-gfx] [PATCH v3 12/12] drm/i915: Listen for PMIC bus access notifications

2017-02-16 Thread Jani Nikula
On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> On Fri, Feb 10, 2017 at 11:28:02AM +0100, Hans de Goede wrote:
>> Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
>> the bus is accessed to avoid needing to do any forcewakes, which need
>> PMIC bus access, while the PMIC bus is busy:
>> 
>> This fixes errors like these showing up in dmesg, usually followed
>> by a gfx or system freeze:
>> 
>> [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake 
>> ack request.
>> [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake 
>> ack request.
>> i2c_designware 808622C1:06: punit semaphore timed out, resetting
>> i2c_designware 808622C1:06: PUNIT SEM: 2
>> i2c_designware 808622C1:06: couldn't acquire bus ownership
>> 
>> Downside of this approach is that it causes wakeups whenever the PMIC
>> bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
>> to go idle when we hit a race, as forcewakes may be done from interrupt
>> handlers where we cannot sleep to wait for the i2c PMIC bus access to
>> finish.
>> 
>> Note that the notifications and thus the wakeups will only happen on
>> baytrail / cherrytrail devices using PMICs with a shared i2c bus for
>> P-Unit and host PMIC access (i2c busses with a _SEM method in their
>> APCI node), e.g. an axp288 PMIC.
>> 
>> I plan to write some patches for drivers accessing the PMIC bus to
>> limit their bus accesses to a bare minimum (e.g. cache registers, do not
>> update battery level more often then 4 times a minute), to limit the
>> amount of wakeups.
>> 
>> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
>> Signed-off-by: Hans de Goede 
>> Tested-by: tagorereddy 
>
> I gave the previous versions a quick whirl on a few machines here, but
> them not being CR versions I guess this stuff doesn't kick in at all.
> And I don't see any _SEM stuff in the DSDT/SSDT, so I guess that
> confirms it. Which is fine since I've not seem any stability issues
> on those machines. So at least nothing seemed to break :)
>
> Anyways the changes look all right to me, so for both i915 patches
> Reviewed-by: Ville Syrjälä 

Acked-by: Jani Nikula 

for merging the i915 patches through some other tree if that makes
managing the pile easier.


>
>> ---
>> Changes in v2:
>> -Spelling: P-Unit, PMIC
>> Changes in v3:
>> -Improve comment explaining why we call intel_uncore_forcewake_get(ALL) on
>>  MBI_PMIC_BUS_ACCESS_BEGIN notification
>> ---
>>  drivers/gpu/drm/i915/Kconfig|  1 +
>>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>>  drivers/gpu/drm/i915/intel_uncore.c | 39 
>> +
>>  3 files changed, 41 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index 1ae0bb9..a5cd5da 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -20,6 +20,7 @@ config DRM_I915
>>  select ACPI_VIDEO if ACPI
>>  select ACPI_BUTTON if ACPI
>>  select SYNC_FILE
>> +select IOSF_MBI
>>  help
>>Choose this option if you have a system that has "Intel Graphics
>>Media Accelerator" or "HD Graphics" integrated graphics,
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 998239f..4e405d0 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -725,6 +725,7 @@ struct intel_uncore {
>>  const struct intel_forcewake_range *fw_domains_table;
>>  unsigned int fw_domains_table_entries;
>>  
>> +struct notifier_block pmic_bus_access_nb;
>>  struct intel_uncore_funcs funcs;
>>  
>>  unsigned fifo_count;
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
>> b/drivers/gpu/drm/i915/intel_uncore.c
>> index b6d726b..1be3cdc 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -25,6 +25,7 @@
>>  #include "intel_drv.h"
>>  #include "i915_vgpu.h"
>>  
>> +#include 
>>  #include 
>>  
>>  #define FORCEWAKE_ACK_TIMEOUT_MS 50
>> @@ -436,12 +437,16 @@ static void __intel_uncore_early_sanitize(struct 
>> drm_i915_private *dev_priv,
>>  
>>  void intel_uncore_suspend(struct drm_i915_private *dev_priv)
>>  {
>> +iosf_mbi_unregister_pmic_bus_access_notifier(
>> +_priv->uncore.pmic_bus_access_nb);
>>  intel_uncore_forcewake_reset(dev_priv, false);
>>  }
>>  
>>  void intel_uncore_resume_early(struct drm_i915_private *dev_priv)
>>  {
>>  __intel_uncore_early_sanitize(dev_priv, true);
>> +iosf_mbi_register_pmic_bus_access_notifier(
>> +_priv->uncore.pmic_bus_access_nb);
>>  i915_check_and_clear_faults(dev_priv);
>>  }
>>  
>> @@ -1329,6 +1334,32 @@ static void intel_uncore_fw_domains_init(struct 
>> drm_i915_private *dev_priv)
>>  dev_priv->uncore.fw_domains_table_entries = 

Re: [Intel-gfx] [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

2017-02-16 Thread Jani Nikula
On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> On Thu, Feb 16, 2017 at 07:54:00PM +0200, Jani Nikula wrote:
>> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
>> > On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
>> >> Handle debugfs override edid and firmware edid at the low level to
>> >> transparently and completely replace the real edid. Previously, we
>> >> practically only used the modes from the override EDID, and none of the
>> >> other data. This also prevents actual EDID reads when the EDID is to be
>> >> overridden, but retains the DDC probe.
>> >
>> > Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
>> > somethign then the override EDID wouldn't be returned by drm_get_edid().
>> 
>> Isn't this in line with how this currently works?
>
> Not really. If connector->force is used and an override EDID is
> provided, then drm_get_edid() likely never gets called, and the modes
> come directly from the overide EDID. With your change forcing the
> connector state wouldn't because we still wouldn't get any modes
> from the override EDID due to the DDC check.

Right.

> I guess one way around this would be to skip the DDC check if the
> connector state has been forced.

I guess I'm asking if you think the whole approach here is
workable. What we currently have is so flaky.

BR,
Jani.

>
>> 
>> BR,
>> Jani.
>> 
>> 
>> >
>> >> 
>> >> FIXME: validate override edid, deduplicate firmware edid validation.
>> >> 
>> >> Signed-off-by: Jani Nikula 
>> >> ---
>> >>  drivers/gpu/drm/drm_edid.c | 15 +++
>> >>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
>> >>  2 files changed, 16 insertions(+), 18 deletions(-)
>> >> 
>> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> >> index 362036360724..054e2d74eafc 100644
>> >> --- a/drivers/gpu/drm/drm_edid.c
>> >> +++ b/drivers/gpu/drm/drm_edid.c
>> >> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct 
>> >> drm_connector *connector,
>> >>   * level, drivers must make all reasonable efforts to expose it as an I2C
>> >>   * adapter and use drm_get_edid() instead of abusing this function.
>> >>   *
>> >> + * The EDID may be overridden using debugfs override_edid or firmare EDID
>> >> + * (drm_load_edid_firmware()), in this priority order. Having either of 
>> >> them
>> >> + * bypasses actual EDID reads.
>> >> + *
>> >>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
>> >>   */
>> >>  struct edid *drm_do_get_edid(struct drm_connector *connector,
>> >> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
>> >> *connector,
>> >>  {
>> >>   int i, j = 0, valid_extensions = 0;
>> >>   u8 *edid, *new;
>> >> + struct edid *override = NULL;
>> >> +
>> >> + if (connector->override_edid)
>> >> + override = drm_edid_duplicate((const struct edid *)
>> >> +   connector->edid_blob_ptr->data);
>> >> +
>> >> + if (!override)
>> >> + override = drm_load_edid_firmware(connector);
>> >> +
>> >> + if (!IS_ERR_OR_NULL(override))
>> >> + return override;
>> >>  
>> >>   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>> >>   return NULL;
>> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> >> b/drivers/gpu/drm/drm_probe_helper.c
>> >> index 358957118ca9..871326cbc465 100644
>> >> --- a/drivers/gpu/drm/drm_probe_helper.c
>> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> >> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
>> >> bool force)
>> >>   *drm_mode_probed_add(). New modes start their life with status as 
>> >> OK.
>> >>   *Modes are added from a single source using the following priority 
>> >> order.
>> >>   *
>> >> - *- debugfs 'override_edid' (used for testing only)
>> >> - *- firmware EDID (drm_load_edid_firmware())
>> >>   *- _connector_helper_funcs.get_modes vfunc
>> >>   *- if the connector status is connector_status_connected, standard
>> >>   *  VESA DMT modes up to 1024x768 are automatically added
>> >> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
>> >> drm_connector *connector,
>> >>   goto prune;
>> >>   }
>> >>  
>> >> - if (connector->override_edid) {
>> >> - struct edid *edid = (struct edid *) 
>> >> connector->edid_blob_ptr->data;
>> >> -
>> >> - count = drm_add_edid_modes(connector, edid);
>> >> - drm_edid_to_eld(connector, edid);
>> >> - } else {
>> >> - struct edid *edid = drm_load_edid_firmware(connector);
>> >> - if (!IS_ERR_OR_NULL(edid)) {
>> >> - drm_mode_connector_update_edid_property(connector, 
>> >> edid);
>> >> - count = drm_add_edid_modes(connector, edid);
>> >> - drm_edid_to_eld(connector, edid);
>> >> - kfree(edid);
>> >> - }
>> >> - if (count == 0)
>> 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease

2017-02-16 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Postpone fake breadcrumb interrupt 
until real interrupts cease
URL   : https://patchwork.freedesktop.org/series/19784/
State : success

== Summary ==

Series 19784v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/19784/revisions/1/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

b29710e319e4b58d994065f5e776f6f66674d7c9 drm-tip: 2017y-02m-16d-15h-35m-40s UTC 
integration manifest
e3d034f drm/i915: Break i915_spin_request() if we see an interrupt
a3223fe drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3859/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

2017-02-16 Thread Oscar Mateo



On 02/14/2017 05:53 AM, Joonas Lahtinen wrote:

Started adding proper teardown to guc_client_alloc, ended up removing
quite a few dead ends where errors communicating with the GuC were
silently ignored. There also seemed to be quite a few erronous
teardown actions performed in case of an error (ordering wrong).

v2:
- Increase function symmetry/proximity (Michal/Daniele)
- Fix __reserve_doorbell accounting for high priority (Daniele)
- Call __update_doorbell_desc! (Daniele)
- Isolate __guc_{,de}allocate_doorbell (Michal/Daniele)

Signed-off-by: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc: Oscar Mateo 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
---
  drivers/gpu/drm/i915/i915_debugfs.c|   4 +-
  drivers/gpu/drm/i915/i915_guc_submission.c | 371 -
  drivers/gpu/drm/i915/intel_guc_fwif.h  |   4 +-
  drivers/gpu/drm/i915/intel_uc.h|  11 +-
  4 files changed, 215 insertions(+), 175 deletions(-)


  
  	/*

 * Since the doorbell only requires a single cacheline, we can save
@@ -753,27 +781,35 @@ guc_client_alloc(struct drm_i915_private *dev_priv,
guc_proc_desc_init(guc, client);
guc_ctx_desc_init(guc, client);
-   /* For runtime client allocation we need to enable the doorbell. Not
-* required yet for the static execbuf_client as this special kernel
-* client is enabled from i915_guc_submission_enable().
-*
-* guc_update_doorbell_id(guc, client, db_id);
-*/
+   /* For runtime client allocation we need to enable the doorbell. */
+   ret = __update_doorbell_desc(client, client->doorbell_id);
+   if (ret)
+   goto err_vaddr;
+
+   ret = __create_doorbell(client);
+   if (ret)
+   goto err_db;
At this point, client->doorbell_id is still invalid (__reserve_doorbell 
is not called until later from guc_init_doorbell_hw), so the 
__create_doorbell fails (and from there, the whole thing falls over: see 
my next comment below). CI.BAT didn't catch it because GuC is disabled 
by default.



DRM_DEBUG_DRIVER("new priority %u client %p for engine(s) 0x%x: ctx_index 
%u\n",
-   priority, client, client->engines, client->ctx_index);
-   DRM_DEBUG_DRIVER("doorbell id %u, cacheline offset 0x%x\n",
-   client->doorbell_id, client->doorbell_offset);
+priority, client, client->engines, client->ctx_index);
+   DRM_DEBUG_DRIVER("doorbell id %u, cacheline offset 0x%lx\n",
+client->doorbell_id, client->doorbell_offset);
  
  	return client;

+err_db:
+   __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
+err_vaddr:
+   i915_gem_object_unpin_map(client->vma->obj);
+err_vma:
+   i915_vma_unpin_and_release(>vma);
+err_id:
+   ida_simple_remove(>ctx_ids, client->ctx_index);
+err_client:
+   kfree(client);
  
-err:

-   guc_client_free(dev_priv, client);
-   return NULL;
+   return ERR_PTR(ret);
  }

I know you are leaving i915_guc_submission_init to me, but this patch 
should as a minimum check the return code from guc_client_alloc, 
otherwise we might end up with an invalid guc->execbuf_client without 
noticing.


Something like this should suffice, and I can take it from there:

@@ -939,7 +939,7 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)

INTEL_INFO(dev_priv)->ring_mask,
GUC_CTX_PRIORITY_KMD_NORMAL,
dev_priv->kernel_context);
-   if (!guc->execbuf_client) {
+   if (IS_ERR(guc->execbuf_client)) {
DRM_ERROR("Failed to create GuC client for execbuf!\n");
goto err;
}
@@ -1016,10 +1016,8 @@ void i915_guc_submission_fini(struct 
drm_i915_private *dev_priv)

struct i915_guc_client *client;

client = fetch_and_zero(>execbuf_client);
-   if (!client)
-   return;
-
-   guc_client_free(client);
+   if (client && !IS_ERR(client))
+   guc_client_free(client);

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


Re: [Intel-gfx] [PATCH v3 12/12] drm/i915: Listen for PMIC bus access notifications

2017-02-16 Thread Ville Syrjälä
On Fri, Feb 10, 2017 at 11:28:02AM +0100, Hans de Goede wrote:
> Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
> the bus is accessed to avoid needing to do any forcewakes, which need
> PMIC bus access, while the PMIC bus is busy:
> 
> This fixes errors like these showing up in dmesg, usually followed
> by a gfx or system freeze:
> 
> [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake 
> ack request.
> [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake 
> ack request.
> i2c_designware 808622C1:06: punit semaphore timed out, resetting
> i2c_designware 808622C1:06: PUNIT SEM: 2
> i2c_designware 808622C1:06: couldn't acquire bus ownership
> 
> Downside of this approach is that it causes wakeups whenever the PMIC
> bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
> to go idle when we hit a race, as forcewakes may be done from interrupt
> handlers where we cannot sleep to wait for the i2c PMIC bus access to
> finish.
> 
> Note that the notifications and thus the wakeups will only happen on
> baytrail / cherrytrail devices using PMICs with a shared i2c bus for
> P-Unit and host PMIC access (i2c busses with a _SEM method in their
> APCI node), e.g. an axp288 PMIC.
> 
> I plan to write some patches for drivers accessing the PMIC bus to
> limit their bus accesses to a bare minimum (e.g. cache registers, do not
> update battery level more often then 4 times a minute), to limit the
> amount of wakeups.
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede 
> Tested-by: tagorereddy 

I gave the previous versions a quick whirl on a few machines here, but
them not being CR versions I guess this stuff doesn't kick in at all.
And I don't see any _SEM stuff in the DSDT/SSDT, so I guess that
confirms it. Which is fine since I've not seem any stability issues
on those machines. So at least nothing seemed to break :)

Anyways the changes look all right to me, so for both i915 patches
Reviewed-by: Ville Syrjälä 

> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> Changes in v3:
> -Improve comment explaining why we call intel_uncore_forcewake_get(ALL) on
>  MBI_PMIC_BUS_ACCESS_BEGIN notification
> ---
>  drivers/gpu/drm/i915/Kconfig|  1 +
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_uncore.c | 39 
> +
>  3 files changed, 41 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 1ae0bb9..a5cd5da 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -20,6 +20,7 @@ config DRM_I915
>   select ACPI_VIDEO if ACPI
>   select ACPI_BUTTON if ACPI
>   select SYNC_FILE
> + select IOSF_MBI
>   help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 998239f..4e405d0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -725,6 +725,7 @@ struct intel_uncore {
>   const struct intel_forcewake_range *fw_domains_table;
>   unsigned int fw_domains_table_entries;
>  
> + struct notifier_block pmic_bus_access_nb;
>   struct intel_uncore_funcs funcs;
>  
>   unsigned fifo_count;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index b6d726b..1be3cdc 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -25,6 +25,7 @@
>  #include "intel_drv.h"
>  #include "i915_vgpu.h"
>  
> +#include 
>  #include 
>  
>  #define FORCEWAKE_ACK_TIMEOUT_MS 50
> @@ -436,12 +437,16 @@ static void __intel_uncore_early_sanitize(struct 
> drm_i915_private *dev_priv,
>  
>  void intel_uncore_suspend(struct drm_i915_private *dev_priv)
>  {
> + iosf_mbi_unregister_pmic_bus_access_notifier(
> + _priv->uncore.pmic_bus_access_nb);
>   intel_uncore_forcewake_reset(dev_priv, false);
>  }
>  
>  void intel_uncore_resume_early(struct drm_i915_private *dev_priv)
>  {
>   __intel_uncore_early_sanitize(dev_priv, true);
> + iosf_mbi_register_pmic_bus_access_notifier(
> + _priv->uncore.pmic_bus_access_nb);
>   i915_check_and_clear_faults(dev_priv);
>  }
>  
> @@ -1329,6 +1334,32 @@ static void intel_uncore_fw_domains_init(struct 
> drm_i915_private *dev_priv)
>   dev_priv->uncore.fw_domains_table_entries = ARRAY_SIZE((d)); \
>  }
>  
> +static int i915_pmic_bus_access_notifier(struct notifier_block *nb,
> +  unsigned long action, void *data)
> +{
> + struct drm_i915_private *dev_priv = container_of(nb,
> + struct drm_i915_private, uncore.pmic_bus_access_nb);
> +
> + switch 

[Intel-gfx] ✓ Fi.CI.BAT: success for Assorted engine tidy (rev3)

2017-02-16 Thread Patchwork
== Series Details ==

Series: Assorted engine tidy (rev3)
URL   : https://patchwork.freedesktop.org/series/19774/
State : success

== Summary ==

Series 19774v3 Assorted engine tidy
https://patchwork.freedesktop.org/api/1.0/series/19774/revisions/3/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

b29710e319e4b58d994065f5e776f6f66674d7c9 drm-tip: 2017y-02m-16d-15h-35m-40s UTC 
integration manifest
2e52ebf drm/i915: Consolidate gen8_emit_pipe_control
8ab28ee drm/i915: Tidy workaround batch buffer emission
dd052d5 drm/i915: Move common workaround code to intel_engine_cs
328eff8 drm/i915: Simplify cleanup path in intel_engines_init
a3d7d79 drm/i915: Make int __intel_ring_space static

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3858/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 07:54:00PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
> >> Handle debugfs override edid and firmware edid at the low level to
> >> transparently and completely replace the real edid. Previously, we
> >> practically only used the modes from the override EDID, and none of the
> >> other data. This also prevents actual EDID reads when the EDID is to be
> >> overridden, but retains the DDC probe.
> >
> > Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
> > somethign then the override EDID wouldn't be returned by drm_get_edid().
> 
> Isn't this in line with how this currently works?

Not really. If connector->force is used and an override EDID is
provided, then drm_get_edid() likely never gets called, and the modes
come directly from the overide EDID. With your change forcing the
connector state wouldn't because we still wouldn't get any modes
from the override EDID due to the DDC check.

I guess one way around this would be to skip the DDC check if the
connector state has been forced.

> 
> BR,
> Jani.
> 
> 
> >
> >> 
> >> FIXME: validate override edid, deduplicate firmware edid validation.
> >> 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/drm_edid.c | 15 +++
> >>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> >>  2 files changed, 16 insertions(+), 18 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 362036360724..054e2d74eafc 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
> >> *connector,
> >>   * level, drivers must make all reasonable efforts to expose it as an I2C
> >>   * adapter and use drm_get_edid() instead of abusing this function.
> >>   *
> >> + * The EDID may be overridden using debugfs override_edid or firmare EDID
> >> + * (drm_load_edid_firmware()), in this priority order. Having either of 
> >> them
> >> + * bypasses actual EDID reads.
> >> + *
> >>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> >>   */
> >>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> >> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
> >> *connector,
> >>  {
> >>int i, j = 0, valid_extensions = 0;
> >>u8 *edid, *new;
> >> +  struct edid *override = NULL;
> >> +
> >> +  if (connector->override_edid)
> >> +  override = drm_edid_duplicate((const struct edid *)
> >> +connector->edid_blob_ptr->data);
> >> +
> >> +  if (!override)
> >> +  override = drm_load_edid_firmware(connector);
> >> +
> >> +  if (!IS_ERR_OR_NULL(override))
> >> +  return override;
> >>  
> >>if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> >>return NULL;
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> index 358957118ca9..871326cbc465 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
> >> bool force)
> >>   *drm_mode_probed_add(). New modes start their life with status as OK.
> >>   *Modes are added from a single source using the following priority 
> >> order.
> >>   *
> >> - *- debugfs 'override_edid' (used for testing only)
> >> - *- firmware EDID (drm_load_edid_firmware())
> >>   *- _connector_helper_funcs.get_modes vfunc
> >>   *- if the connector status is connector_status_connected, standard
> >>   *  VESA DMT modes up to 1024x768 are automatically added
> >> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
> >> drm_connector *connector,
> >>goto prune;
> >>}
> >>  
> >> -  if (connector->override_edid) {
> >> -  struct edid *edid = (struct edid *) 
> >> connector->edid_blob_ptr->data;
> >> -
> >> -  count = drm_add_edid_modes(connector, edid);
> >> -  drm_edid_to_eld(connector, edid);
> >> -  } else {
> >> -  struct edid *edid = drm_load_edid_firmware(connector);
> >> -  if (!IS_ERR_OR_NULL(edid)) {
> >> -  drm_mode_connector_update_edid_property(connector, 
> >> edid);
> >> -  count = drm_add_edid_modes(connector, edid);
> >> -  drm_edid_to_eld(connector, edid);
> >> -  kfree(edid);
> >> -  }
> >> -  if (count == 0)
> >> -  count = (*connector_funcs->get_modes)(connector);
> >> -  }
> >> +  count = (*connector_funcs->get_modes)(connector);
> >>  
> >>if (count == 0 && connector->status == connector_status_connected)
> >>count = drm_add_modes_noedid(connector, 1024, 768);
> >> -- 
> 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE PATCHES (rev5)

2017-02-16 Thread Jani Nikula
On Thu, 16 Feb 2017, "Chauhan, Madhav"  wrote:
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Thursday, February 16, 2017 8:49 PM
>> To: Patchwork ; Chauhan, Madhav
>> 
>> Cc: intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE
>> PATCHES (rev5)
>> 
>> On Tue, 14 Feb 2017, Patchwork 
>> wrote:
>> > drivers/gpu/drm/i915/intel_dsi_pll.c: In function ‘intel_compute_dsi_pll’:
>> > drivers/gpu/drm/i915/intel_dsi_pll.c:513:45: error: ‘dsi_ratio_max’ may be
>> used uninitialized in this function [-Werror=maybe-uninitialized]
>> >   if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
>> >  ^
>> > drivers/gpu/drm/i915/intel_dsi_pll.c:492:31: note: ‘dsi_ratio_max’ was
>> declared here
>> >   u8 dsi_ratio, dsi_ratio_min, dsi_ratio_max;
>> >^
>> >   LD  drivers/tty/serial/built-in.o
>> >   LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
>> > cc1: all warnings being treated as errors
>> > scripts/Makefile.build:294: recipe for target
>> > 'drivers/gpu/drm/i915/intel_dsi_pll.o' failed
>> > make[4]: *** [drivers/gpu/drm/i915/intel_dsi_pll.o] Error 1
>> > make[4]: *** Waiting for unfinished jobs
>> 
>> The series didn't get tested because of this. Please update the series and
>> repost, and do remember to add the Reviewed-by tags to the patches I've
>> reviewed so far.
>
> Agree. Surprised to see why I didn’t get this error during compilation
> in my local environment. Used x86_64_defconfig. Any idea ??

The CI usees DRM_I915_WERROR=y, among other debug config options.

BR,
Jani.


>
>> 
>> Thanks,
>> Jani.
>> 
>> 
>> 
>> --
>> Jani Nikula, Intel Open Source Technology Center

-- 
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] [PATCH 04/18] drm/i915: Plop vlv wm state into crtc_state

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Relocate the vlv/chv wm state to live under intel_crtc_state. Note
that for now this just behaves as a temporary storage. But it'll be
easier to conver the thing over to properly pre-computing the state
when it's already in the right place.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_drv.h | 30 +-
 drivers/gpu/drm/i915/intel_pm.c  | 32 
 2 files changed, 37 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f4ba686e3e22..82caf4f4a02b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -488,6 +488,22 @@ struct skl_pipe_wm {
uint32_t linetime;
 };
 
+enum vlv_wm_level {
+   VLV_WM_LEVEL_PM2,
+   VLV_WM_LEVEL_PM5,
+   VLV_WM_LEVEL_DDR_DVFS,
+   NUM_VLV_WM_LEVELS,
+};
+
+struct vlv_wm_state {
+   struct vlv_pipe_wm wm[NUM_VLV_WM_LEVELS];
+   struct vlv_sr_wm sr[NUM_VLV_WM_LEVELS];
+   uint8_t num_active_planes;
+   uint8_t num_levels;
+   uint8_t level;
+   bool cxsr;
+};
+
 struct intel_crtc_wm_state {
union {
struct {
@@ -512,6 +528,11 @@ struct intel_crtc_wm_state {
struct skl_pipe_wm optimal;
struct skl_ddb_entry ddb;
} skl;
+
+   struct {
+   /* inverted optimal watermarks */
+   struct vlv_wm_state optimal;
+   } vlv;
};
 
/*
@@ -696,15 +717,6 @@ struct intel_crtc_state {
u8 active_planes;
 };
 
-struct vlv_wm_state {
-   struct vlv_pipe_wm wm[3];
-   struct vlv_sr_wm sr[3];
-   uint8_t num_active_planes;
-   uint8_t num_levels;
-   uint8_t level;
-   bool cxsr;
-};
-
 struct vlv_fifo_state {
uint16_t plane[I915_MAX_PLANES];
 };
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b29b05a195d8..507e49cd6e4a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -947,12 +947,6 @@ static void vlv_write_wm_values(struct drm_i915_private 
*dev_priv,
 
 #undef FW_WM_VLV
 
-enum vlv_wm_level {
-   VLV_WM_LEVEL_PM2,
-   VLV_WM_LEVEL_PM5,
-   VLV_WM_LEVEL_DDR_DVFS,
-};
-
 /* latency must be in 0.1us units. */
 static unsigned int vlv_wm_method2(unsigned int pixel_rate,
   unsigned int pipe_htotal,
@@ -1023,9 +1017,10 @@ static uint16_t vlv_compute_wm_level(const struct 
intel_crtc_state *crtc_state,
return min_t(int, wm, USHRT_MAX);
 }
 
-static void vlv_compute_fifo(struct intel_crtc *crtc)
+static void vlv_compute_fifo(struct intel_crtc_state *crtc_state)
 {
-   struct vlv_wm_state *wm_state = >wm.active.vlv;
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
struct vlv_fifo_state *fifo_state = >wm.fifo_state;
struct drm_device *dev = crtc->base.dev;
struct intel_plane *plane;
@@ -1099,9 +1094,10 @@ static u16 vlv_invert_wm_value(u16 wm, u16 fifo_size)
return fifo_size - wm;
 }
 
-static void vlv_invert_wms(struct intel_crtc *crtc)
+static void vlv_invert_wms(struct intel_crtc_state *crtc_state)
 {
-   struct vlv_wm_state *wm_state = >wm.active.vlv;
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+   struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
int level;
 
for (level = 0; level < wm_state->num_levels; level++) {
@@ -1126,10 +1122,11 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
}
 }
 
-static void vlv_compute_wm(struct intel_crtc *crtc)
+static void vlv_compute_wm(struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct vlv_wm_state *wm_state = >wm.active.vlv;
+   struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
const struct vlv_fifo_state *fifo_state = >wm.fifo_state;
struct intel_plane *plane;
int level;
@@ -1141,7 +1138,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
 
wm_state->num_active_planes = 0;
 
-   vlv_compute_fifo(crtc);
+   vlv_compute_fifo(crtc_state);
 
if (wm_state->num_active_planes != 1)
wm_state->cxsr = false;
@@ -1156,7 +1153,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
 
/* normal watermarks */
for (level = 0; level < wm_state->num_levels; level++) {
-   int wm = vlv_compute_wm_level(crtc->config, state, 
level);
+   int wm = vlv_compute_wm_level(crtc_state, state, level);
 

[Intel-gfx] [PATCH 07/18] drm/i915: Compute vlv/chv wms the atomic way

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Start computing the vlv/chv watermarks the atomic way, from the
.compute_pipe_wm() hook. We'll recompute the actual watermarks
for only planes that are part of the state, the other planes will
keep their watermark from the last time it was computed.

And the actual watermark programming will happen from the
.initial_watermarks() hook. For now we'll just compute the
optimal watermarks, and we'll hook up the intermediate
watermarks properly later.

The DSPARB registers responsible for the FIFO paritioning are
double buffered, so they will be programming from
intel_begin_crtc_commit().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |   8 +
 drivers/gpu/drm/i915/intel_display.c |  21 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 -
 drivers/gpu/drm/i915/intel_pm.c  | 327 +++
 4 files changed, 238 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7495a16b869a..e7317827cf0b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -500,6 +500,14 @@ struct i915_hotplug {
for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
for_each_if (BIT_ULL(domain) & (mask))
 
+#define for_each_intel_plane_in_state(__state, plane, plane_state, __i) \
+   for ((__i) = 0; \
+(__i) < (__state)->base.dev->mode_config.num_total_plane && \
+((plane) = 
to_intel_plane((__state)->base.planes[__i].ptr), \
+ (plane_state) = 
to_intel_plane_state((__state)->base.planes[__i].state), 1); \
+(__i)++) \
+   for_each_if (plane_state)
+
 struct drm_i915_private;
 struct i915_mm_struct;
 struct i915_mmu_object;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0ccc04607b8a..77160eaa2294 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5763,6 +5763,8 @@ static void modeset_put_power_domains(struct 
drm_i915_private *dev_priv,
 static void valleyview_crtc_enable(struct intel_crtc_state *pipe_config,
   struct drm_atomic_state *old_state)
 {
+   struct intel_atomic_state *old_intel_state =
+   to_intel_atomic_state(old_state);
struct drm_crtc *crtc = pipe_config->base.crtc;
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -5807,7 +5809,8 @@ static void valleyview_crtc_enable(struct 
intel_crtc_state *pipe_config,
 
intel_color_load_luts(_config->base);
 
-   intel_update_watermarks(intel_crtc);
+   dev_priv->display.initial_watermarks(old_intel_state,
+pipe_config);
intel_enable_pipe(intel_crtc);
 
assert_vblank_disabled(crtc);
@@ -5924,6 +5927,9 @@ static void i9xx_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
 
if (!IS_GEN2(dev_priv))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
+
+   if (!dev_priv->display.initial_watermarks)
+   intel_update_watermarks(intel_crtc);
 }
 
 static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
@@ -11362,10 +11368,13 @@ static bool check_digital_port_conflicts(struct 
drm_atomic_state *state)
 static void
 clear_intel_crtc_state(struct intel_crtc_state *crtc_state)
 {
+   struct drm_i915_private *dev_priv =
+   to_i915(crtc_state->base.crtc->dev);
struct drm_crtc_state tmp_state;
struct intel_crtc_scaler_state scaler_state;
struct intel_dpll_hw_state dpll_hw_state;
struct intel_shared_dpll *shared_dpll;
+   struct intel_crtc_wm_state wm_state;
bool force_thru;
 
/* FIXME: before the switch to atomic started, a new pipe_config was
@@ -11378,6 +11387,8 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
shared_dpll = crtc_state->shared_dpll;
dpll_hw_state = crtc_state->dpll_hw_state;
force_thru = crtc_state->pch_pfit.force_thru;
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   wm_state = crtc_state->wm;
 
memset(crtc_state, 0, sizeof *crtc_state);
 
@@ -11386,6 +11397,8 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
crtc_state->shared_dpll = shared_dpll;
crtc_state->dpll_hw_state = dpll_hw_state;
crtc_state->pch_pfit.force_thru = force_thru;
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   crtc_state->wm = wm_state;
 }
 
 static int
@@ -12898,12 +12911,12 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
/*
 * Make sure we don't call initial_watermarks
 * for ILK-style watermark 

[Intel-gfx] [PATCH 14/18] drm/i915: Kill level 0 wm hack for VLV/CHV

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

We now compute the watermarks correctly, so just return an error if we
can't support the configuration.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 23600ad1dfcf..fbd9cfba720a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1175,10 +1175,6 @@ static bool vlv_plane_wm_compute(struct intel_crtc_state 
*crtc_state,
int wm = vlv_compute_wm_level(crtc_state, plane_state, level);
int max_wm = plane_id == PLANE_CURSOR ? 63 : 511;
 
-   /* FIXME just bail */
-   if (WARN_ON(level == 0 && wm > max_wm))
-   wm = max_wm;
-
if (wm > max_wm)
break;
 
-- 
2.10.2

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


[Intel-gfx] [PATCH 16/18] drm/i915: Add VLV/CHV watermark/FIFO programming tracepoints

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Add tracepoints for observing the WM/FIFO programming on VLV/CHV. When
compared with the plane and pipe update tracepoints this can be used
to verify that everything is performed in the right sequence.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_trace.h | 71 +++
 drivers/gpu/drm/i915/intel_pm.c   |  4 +++
 2 files changed, 75 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 6354b71fc6a7..865084fd8455 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -14,6 +14,77 @@
 #define TRACE_SYSTEM i915
 #define TRACE_INCLUDE_FILE i915_trace
 
+/* watermark/fifo updates */
+
+TRACE_EVENT(vlv_wm,
+   TP_PROTO(struct intel_crtc *crtc, const struct vlv_wm_values *wm),
+   TP_ARGS(crtc, wm),
+
+   TP_STRUCT__entry(
+__field(enum pipe, pipe)
+__field(u32, frame)
+__field(u32, scanline)
+__field(u32, level)
+__field(u32, cxsr)
+__field(u32, primary)
+__field(u32, sprite0)
+__field(u32, sprite1)
+__field(u32, cursor)
+__field(u32, sr_plane)
+__field(u32, sr_cursor)
+),
+
+   TP_fast_assign(
+  __entry->pipe = crtc->pipe;
+  __entry->frame = 
crtc->base.dev->driver->get_vblank_counter(crtc->base.dev,
+   
   crtc->pipe);
+  __entry->scanline = intel_get_crtc_scanline(crtc);
+  __entry->level = wm->level;
+  __entry->cxsr = wm->cxsr;
+  __entry->primary = 
wm->pipe[crtc->pipe].plane[PLANE_PRIMARY];
+  __entry->sprite0 = 
wm->pipe[crtc->pipe].plane[PLANE_SPRITE0];
+  __entry->sprite1 = 
wm->pipe[crtc->pipe].plane[PLANE_SPRITE1];
+  __entry->cursor = 
wm->pipe[crtc->pipe].plane[PLANE_CURSOR];
+  __entry->sr_plane = wm->sr.plane;
+  __entry->sr_cursor = wm->sr.cursor;
+  ),
+
+   TP_printk("pipe %c, frame=%u, scanline=%u, level=%d, cxsr=%d, wm 
%d/%d/%d/%d, sr %d/%d",
+ pipe_name(__entry->pipe), __entry->frame,
+ __entry->scanline, __entry->level, __entry->cxsr,
+ __entry->primary, __entry->sprite0, __entry->sprite1, 
__entry->cursor,
+ __entry->sr_plane, __entry->sr_cursor)
+);
+
+TRACE_EVENT(vlv_fifo_size,
+   TP_PROTO(struct intel_crtc *crtc, u32 sprite0_start, u32 
sprite1_start, u32 fifo_size),
+   TP_ARGS(crtc, sprite0_start, sprite1_start, fifo_size),
+
+   TP_STRUCT__entry(
+__field(enum pipe, pipe)
+__field(u32, frame)
+__field(u32, scanline)
+__field(u32, sprite0_start)
+__field(u32, sprite1_start)
+__field(u32, fifo_size)
+),
+
+   TP_fast_assign(
+  __entry->pipe = crtc->pipe;
+  __entry->frame = 
crtc->base.dev->driver->get_vblank_counter(crtc->base.dev,
+   
   crtc->pipe);
+  __entry->scanline = intel_get_crtc_scanline(crtc);
+  __entry->sprite0_start = sprite0_start;
+  __entry->sprite1_start = sprite1_start;
+  __entry->fifo_size = fifo_size;
+  ),
+
+   TP_printk("pipe %c, frame=%u, scanline=%u, %d/%d/%d",
+ pipe_name(__entry->pipe), __entry->frame,
+ __entry->scanline, __entry->sprite0_start,
+ __entry->sprite1_start, __entry->fifo_size)
+);
+
 /* plane updates */
 
 TRACE_EVENT(intel_update_plane,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fbd9cfba720a..69b52da19f6d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -878,6 +878,8 @@ static void vlv_write_wm_values(struct drm_i915_private 
*dev_priv,
enum pipe pipe;
 
for_each_pipe(dev_priv, pipe) {
+   trace_vlv_wm(intel_get_crtc_for_pipe(dev_priv, pipe), wm);
+
I915_WRITE(VLV_DDL(pipe),
   (wm->ddl[pipe].plane[PLANE_CURSOR] << 
DDL_CURSOR_SHIFT) 

[Intel-gfx] [PATCH 15/18] drm/i915: Add plane update/disable tracepoints

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Add tracepoints for plane programming. The tracepoints will dump
the frame and scanline counters, so this can be used to verify eg. that
the plane gets reprogrammed at the right time with respect to watermark
programming (if we have appropriate tracepoints for that as well).

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c   |  3 ++
 drivers/gpu/drm/i915/i915_trace.h | 56 +++
 drivers/gpu/drm/i915/intel_atomic_plane.c | 11 --
 drivers/gpu/drm/i915/intel_display.c  |  9 -
 4 files changed, 76 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 91be31617e78..5a4d483062b9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -783,6 +783,9 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
enum pipe pipe = crtc->pipe;
int position, vtotal;
 
+   if (!crtc->active)
+   return -1;
+
vtotal = mode->crtc_vtotal;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
vtotal /= 2;
diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 7a547cdfc381..6354b71fc6a7 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -14,6 +14,62 @@
 #define TRACE_SYSTEM i915
 #define TRACE_INCLUDE_FILE i915_trace
 
+/* plane updates */
+
+TRACE_EVENT(intel_update_plane,
+   TP_PROTO(struct drm_plane *plane, struct intel_crtc *crtc),
+   TP_ARGS(plane, crtc),
+
+   TP_STRUCT__entry(
+__field(enum pipe, pipe)
+__field(const char *, name)
+__field(u32, frame)
+__field(u32, scanline)
+__array(int, src, 4)
+__array(int, dst, 4)
+),
+
+   TP_fast_assign(
+  __entry->pipe = crtc->pipe;
+  __entry->name = plane->name;
+  __entry->frame = 
crtc->base.dev->driver->get_vblank_counter(crtc->base.dev,
+   
   crtc->pipe);
+  __entry->scanline = intel_get_crtc_scanline(crtc);
+  memcpy(__entry->src, >state->src, 
sizeof(__entry->src));
+  memcpy(__entry->dst, >state->dst, 
sizeof(__entry->dst));
+  ),
+
+   TP_printk("pipe %c, plane %s, frame=%u, scanline=%u, " 
DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,
+ pipe_name(__entry->pipe), __entry->name,
+ __entry->frame, __entry->scanline,
+ DRM_RECT_FP_ARG((const struct drm_rect *)__entry->src),
+ DRM_RECT_ARG((const struct drm_rect *)__entry->dst))
+);
+
+TRACE_EVENT(intel_disable_plane,
+   TP_PROTO(struct drm_plane *plane, struct intel_crtc *crtc),
+   TP_ARGS(plane, crtc),
+
+   TP_STRUCT__entry(
+__field(enum pipe, pipe)
+__field(const char *, name)
+__field(u32, frame)
+__field(u32, scanline)
+),
+
+   TP_fast_assign(
+  __entry->pipe = crtc->pipe;
+  __entry->name = plane->name;
+  __entry->frame = 
crtc->base.dev->driver->get_vblank_counter(crtc->base.dev,
+   
   crtc->pipe);
+  __entry->scanline = intel_get_crtc_scanline(crtc);
+  ),
+
+   TP_printk("pipe %c, plane %s, frame=%u, scanline=%u",
+ pipe_name(__entry->pipe), __entry->name,
+ __entry->frame, __entry->scanline)
+);
+
 /* pipe updates */
 
 TRACE_EVENT(i915_pipe_update_start,
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 1eaf840cf9ff..cfb47293fd53 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -231,12 +231,19 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
to_intel_plane_state(plane->state);
struct drm_crtc *crtc = plane->state->crtc ?: old_state->crtc;
 
-   if (intel_state->base.visible)
+   if (intel_state->base.visible) {
+   trace_intel_update_plane(plane,
+to_intel_crtc(crtc));
+
intel_plane->update_plane(plane,
  to_intel_crtc_state(crtc->state),
  intel_state);
-   

[Intel-gfx] [PATCH 18/18] drm/i915: Add FIFO underrun tracepoints

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Add tracepoints for display FIFO underruns. Makes it more convenient to
correlate the underruns with other display tracepoints.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_trace.h  | 43 ++
 drivers/gpu/drm/i915/intel_fifo_underrun.c | 11 ++--
 2 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index bca46406030d..b0eff4d6d5fa 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -16,6 +16,49 @@
 
 /* watermark/fifo updates */
 
+TRACE_EVENT(i915_cpu_fifo_underrun,
+   TP_PROTO(struct drm_i915_private *dev_priv, enum pipe pipe),
+   TP_ARGS(dev_priv, pipe),
+
+   TP_STRUCT__entry(
+__field(enum pipe, pipe)
+__field(u32, frame)
+__field(u32, scanline)
+),
+
+   TP_fast_assign(
+  __entry->pipe = pipe;
+  __entry->frame = 
dev_priv->drm.driver->get_vblank_counter(_priv->drm, pipe);
+  __entry->scanline = 
intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, pipe));
+  ),
+
+   TP_printk("pipe %c, frame=%u, scanline=%u",
+ pipe_name(__entry->pipe),
+ __entry->frame, __entry->scanline)
+);
+
+TRACE_EVENT(i915_pch_fifo_underrun,
+   TP_PROTO(struct drm_i915_private *dev_priv, enum transcoder 
pch_transcoder),
+   TP_ARGS(dev_priv, pch_transcoder),
+
+   TP_STRUCT__entry(
+__field(enum pipe, pipe)
+__field(u32, frame)
+__field(u32, scanline)
+),
+
+   TP_fast_assign(
+  enum pipe pipe = (enum pipe)pch_transcoder;
+  __entry->pipe = pipe;
+  __entry->frame = 
dev_priv->drm.driver->get_vblank_counter(_priv->drm, pipe);
+  __entry->scanline = 
intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, pipe));
+  ),
+
+   TP_printk("pch transcoder %c, frame=%u, scanline=%u",
+ pipe_name(__entry->pipe),
+ __entry->frame, __entry->scanline)
+);
+
 TRACE_EVENT(intel_memory_cxsr,
TP_PROTO(struct drm_i915_private *dev_priv, bool old, bool new),
TP_ARGS(dev_priv, old, new),
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index e660d8b4bbc3..9c2eebaa5253 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -98,6 +98,7 @@ static void i9xx_check_fifo_underruns(struct intel_crtc *crtc)
I915_WRITE(reg, pipestat | PIPE_FIFO_UNDERRUN_STATUS);
POSTING_READ(reg);
 
+   trace_i915_cpu_fifo_underrun(dev_priv, crtc->pipe);
DRM_ERROR("pipe %c underrun\n", pipe_name(crtc->pipe));
 }
 
@@ -147,6 +148,7 @@ static void ivybridge_check_fifo_underruns(struct 
intel_crtc *crtc)
I915_WRITE(GEN7_ERR_INT, ERR_INT_FIFO_UNDERRUN(pipe));
POSTING_READ(GEN7_ERR_INT);
 
+   trace_i915_cpu_fifo_underrun(dev_priv, pipe);
DRM_ERROR("fifo underrun on pipe %c\n", pipe_name(pipe));
 }
 
@@ -212,6 +214,7 @@ static void cpt_check_pch_fifo_underruns(struct intel_crtc 
*crtc)
I915_WRITE(SERR_INT, SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
POSTING_READ(SERR_INT);
 
+   trace_i915_pch_fifo_underrun(dev_priv, pch_transcoder);
DRM_ERROR("pch fifo underrun on pch transcoder %s\n",
  transcoder_name(pch_transcoder));
 }
@@ -368,9 +371,11 @@ void intel_cpu_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
crtc->cpu_fifo_underrun_disabled)
return;
 
-   if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false))
+   if (intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false)) {
+   trace_i915_cpu_fifo_underrun(dev_priv, pipe);
DRM_ERROR("CPU pipe %c FIFO underrun\n",
  pipe_name(pipe));
+   }
 
intel_fbc_handle_fifo_underrun_irq(dev_priv);
 }
@@ -388,9 +393,11 @@ void intel_pch_fifo_underrun_irq_handler(struct 
drm_i915_private *dev_priv,
 enum transcoder pch_transcoder)
 {
if (intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
- false))
+ false)) {
+   trace_i915_pch_fifo_underrun(dev_priv, pch_transcoder);
DRM_ERROR("PCH transcoder %s FIFO underrun\n",
  

[Intel-gfx] [PATCH 13/18] drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

On VLV/CHV enabling sprite0 when sprite1 has already been enabled may
lead to an underrun. This only happens when sprite0 FIFO size is zero
prior to enabling it. Hence an effective workaround is to always
allocate at least one cacheline for sprite0 when sprite1 is active.

I've not observed this sort of failure during any other type of plane
enable/disable sequence.

Testcase: igt/kms_plane_blinker
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 558a4e5b42b0..23600ad1dfcf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1018,6 +1018,12 @@ static uint16_t vlv_compute_wm_level(const struct 
intel_crtc_state *crtc_state,
return min_t(int, wm, USHRT_MAX);
 }
 
+static bool vlv_need_sprite0_fifo_workaround(unsigned int active_planes)
+{
+   return (active_planes & (BIT(PLANE_SPRITE0) |
+BIT(PLANE_SPRITE1))) == BIT(PLANE_SPRITE1);
+}
+
 static int vlv_compute_fifo(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -1028,12 +1034,25 @@ static int vlv_compute_fifo(struct intel_crtc_state 
*crtc_state)
int num_active_planes = hweight32(active_planes);
const int fifo_size = 511;
int fifo_extra, fifo_left = fifo_size;
+   int sprite0_fifo_extra = 0;
unsigned int total_rate;
enum plane_id plane_id;
 
+   /*
+* When enabling sprite0 after sprite1 has already been enabled
+* we tend to get an underrun unless sprite0 already has some
+* FIFO space allcoated. Hence we always allocate at least one
+* cacheline for sprite0 whenever sprite1 is enabled.
+*
+* All other plane enable sequences appear immune to this problem.
+*/
+   if (vlv_need_sprite0_fifo_workaround(active_planes))
+   sprite0_fifo_extra = 1;
+
total_rate = noninverted->plane[PLANE_PRIMARY] +
noninverted->plane[PLANE_SPRITE0] +
-   noninverted->plane[PLANE_SPRITE1];
+   noninverted->plane[PLANE_SPRITE1] +
+   sprite0_fifo_extra;
 
if (total_rate > fifo_size)
return -EINVAL;
@@ -1054,6 +1073,9 @@ static int vlv_compute_fifo(struct intel_crtc_state 
*crtc_state)
fifo_left -= fifo_state->plane[plane_id];
}
 
+   fifo_state->plane[PLANE_SPRITE0] += sprite0_fifo_extra;
+   fifo_left -= sprite0_fifo_extra;
+
fifo_state->plane[PLANE_CURSOR] = 63;
 
fifo_extra = DIV_ROUND_UP(fifo_left, num_active_planes ?: 1);
-- 
2.10.2

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


[Intel-gfx] [PATCH 17/18] drm/i915: Add cxsr toggle tracepoint

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Add a tracepoint for observing changes in the cxsr state. The tracepoint
will dump out the frame and scanline counters for each pipe so that the
information can be compared with eg. plane update tracepoints.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_trace.h | 30 ++
 drivers/gpu/drm/i915/intel_pm.c   |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 865084fd8455..bca46406030d 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -16,6 +16,36 @@
 
 /* watermark/fifo updates */
 
+TRACE_EVENT(intel_memory_cxsr,
+   TP_PROTO(struct drm_i915_private *dev_priv, bool old, bool new),
+   TP_ARGS(dev_priv, old, new),
+
+   TP_STRUCT__entry(
+__array(u32, frame, 3)
+__array(u32, scanline, 3)
+__field(bool, old)
+__field(bool, new)
+),
+
+   TP_fast_assign(
+  enum pipe pipe;
+  for_each_pipe(dev_priv, pipe) {
+  __entry->frame[pipe] =
+  
dev_priv->drm.driver->get_vblank_counter(_priv->drm, pipe);
+  __entry->scanline[pipe] =
+  
intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, pipe));
+  }
+  __entry->old = old;
+  __entry->new = new;
+  ),
+
+   TP_printk("%s->%s, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, 
scanline=%u, pipe C: frame=%u, scanline=%u",
+ onoff(__entry->old), onoff(__entry->new),
+ __entry->frame[PIPE_A], __entry->scanline[PIPE_A],
+ __entry->frame[PIPE_B], __entry->scanline[PIPE_B],
+ __entry->frame[PIPE_C], __entry->scanline[PIPE_C])
+);
+
 TRACE_EVENT(vlv_wm,
TP_PROTO(struct intel_crtc *crtc, const struct vlv_wm_values *wm),
TP_ARGS(crtc, wm),
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 69b52da19f6d..0cba41d94863 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -367,6 +367,8 @@ static bool _intel_set_memory_cxsr(struct drm_i915_private 
*dev_priv, bool enabl
return false;
}
 
+   trace_intel_memory_cxsr(dev_priv, was_enabled, enable);
+
DRM_DEBUG_KMS("memory self-refresh is %s (was %s)\n",
  enableddisabled(enable),
  enableddisabled(was_enabled));
-- 
2.10.2

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


[Intel-gfx] [PATCH v2 02/18] drm/i915: Track plane fifo sizes under intel_crtc

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Track the plane fifo sizes under intel_crtc instead of under each
intel_plane. Avoids looping over the planes in a bunch of places,
and later we'll move this tracking into the crtc state properly.

v2: Nuke intel_plane_wm_parameters (Maarten)

Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_drv.h |  32 ++-
 drivers/gpu/drm/i915/intel_pm.c  | 115 ---
 2 files changed, 54 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e1f28dd61821..a6ee05b0404a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -705,6 +705,10 @@ struct vlv_wm_state {
bool cxsr;
 };
 
+struct vlv_fifo_state {
+   uint16_t plane[I915_MAX_PLANES];
+};
+
 struct intel_crtc {
struct drm_crtc base;
enum pipe pipe;
@@ -754,6 +758,8 @@ struct intel_crtc {
 
/* allow CxSR on this pipe */
bool cxsr_allowed;
+
+   struct vlv_fifo_state fifo_state;
} wm;
 
int scanline_offset;
@@ -771,25 +777,6 @@ struct intel_crtc {
struct vlv_wm_state wm_state;
 };
 
-struct intel_plane_wm_parameters {
-   uint32_t horiz_pixels;
-   uint32_t vert_pixels;
-   /*
-*   For packed pixel formats:
-* bytes_per_pixel - holds bytes per pixel
-*   For planar pixel formats:
-* bytes_per_pixel - holds bytes per pixel for uv-plane
-* y_bytes_per_pixel - holds bytes per pixel for y-plane
-*/
-   uint8_t bytes_per_pixel;
-   uint8_t y_bytes_per_pixel;
-   bool enabled;
-   bool scaled;
-   u64 tiling;
-   unsigned int rotation;
-   uint16_t fifo_size;
-};
-
 struct intel_plane {
struct drm_plane base;
u8 plane;
@@ -799,13 +786,6 @@ struct intel_plane {
int max_downscale;
uint32_t frontbuffer_bit;
 
-   /* Since we need to change the watermarks before/after
-* enabling/disabling the planes, we need to store the parameters here
-* as the other pieces of the struct may not reflect the values we want
-* for the watermark calculations. Currently only Haswell uses this.
-*/
-   struct intel_plane_wm_parameters wm;
-
/*
 * NOTE: Do not place new plane state fields here (e.g., when adding
 * new plane properties).  New runtime state should now be placed in
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fe243c65de1a..06826945576e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -405,15 +405,14 @@ static const int pessimal_latency_ns = 5000;
 #define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
dsparb) >> (lo_shift)) & 0xff) | dsparb2) >> (hi_shift)) & 0x1) 
<< 8))
 
-static int vlv_get_fifo_size(struct intel_plane *plane)
+static void vlv_get_fifo_size(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
-   int sprite0_start, sprite1_start, size;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   struct vlv_fifo_state *fifo_state = >wm.fifo_state;
+   enum pipe pipe = crtc->pipe;
+   int sprite0_start, sprite1_start;
 
-   if (plane->id == PLANE_CURSOR)
-   return 63;
-
-   switch (plane->pipe) {
+   switch (pipe) {
uint32_t dsparb, dsparb2, dsparb3;
case PIPE_A:
dsparb = I915_READ(DSPARB);
@@ -434,26 +433,21 @@ static int vlv_get_fifo_size(struct intel_plane *plane)
sprite1_start = VLV_FIFO_START(dsparb3, dsparb2, 8, 20);
break;
default:
-   return 0;
+   MISSING_CASE(pipe);
+   return;
}
 
-   switch (plane->id) {
-   case PLANE_PRIMARY:
-   size = sprite0_start;
-   break;
-   case PLANE_SPRITE0:
-   size = sprite1_start - sprite0_start;
-   break;
-   case PLANE_SPRITE1:
-   size = 512 - 1 - sprite1_start;
-   break;
-   default:
-   return 0;
-   }
-
-   DRM_DEBUG_KMS("%s FIFO size: %d\n", plane->base.name, size);
+   fifo_state->plane[PLANE_PRIMARY] = sprite0_start;
+   fifo_state->plane[PLANE_SPRITE0] = sprite1_start - sprite0_start;
+   fifo_state->plane[PLANE_SPRITE1] = 511 - sprite1_start;
+   fifo_state->plane[PLANE_CURSOR] = 63;
 
-   return size;
+   DRM_DEBUG_KMS("Pipe %c FIFO size: %d/%d/%d/%d\n",
+ pipe_name(pipe),
+ fifo_state->plane[PLANE_PRIMARY],
+ fifo_state->plane[PLANE_SPRITE0],
+ fifo_state->plane[PLANE_SPRITE1],
+ 

[Intel-gfx] [PATCH 12/18] drm/i915: Sanitize VLV/CHV watermarks properly

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Clear out the watermark for all disabled planes to 0. This is required
to avoid falsely thinking that the inherited watermarks are bogus in
case the watermark is actually higher than the FIFO size.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 17 +++-
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 50 +++-
 3 files changed, 61 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a8f28e776879..9fef24944c8e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3481,7 +3481,8 @@ __intel_display_resume(struct drm_device *dev,
}
 
/* ignore any reset values/BIOS leftovers in the WM registers */
-   to_intel_atomic_state(state)->skip_intermediate_wm = true;
+   if (!HAS_GMCH_DISPLAY(to_i915(dev)))
+   to_intel_atomic_state(state)->skip_intermediate_wm = true;
 
ret = drm_atomic_helper_commit_duplicated_state(state, ctx);
 
@@ -14952,7 +14953,8 @@ static void sanitize_watermarks(struct drm_device *dev)
 * intermediate watermarks (since we don't trust the current
 * watermarks).
 */
-   intel_state->skip_intermediate_wm = true;
+   if (!HAS_GMCH_DISPLAY(dev_priv))
+   intel_state->skip_intermediate_wm = true;
 
ret = intel_atomic_check(dev, state);
if (ret) {
@@ -15116,7 +15118,8 @@ int intel_modeset_init(struct drm_device *dev)
 * Note that we need to do this after reconstructing the BIOS fb's
 * since the watermark calculation done here will use pstate->fb.
 */
-   sanitize_watermarks(dev);
+   if (!HAS_GMCH_DISPLAY(dev_priv))
+   sanitize_watermarks(dev);
 
return 0;
 }
@@ -15567,12 +15570,14 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
pll->on = false;
}
 
-   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
vlv_wm_get_hw_state(dev);
-   else if (IS_GEN9(dev_priv))
+   vlv_wm_sanitize(dev_priv);
+   } else if (IS_GEN9(dev_priv)) {
skl_wm_get_hw_state(dev);
-   else if (HAS_PCH_SPLIT(dev_priv))
+   } else if (HAS_PCH_SPLIT(dev_priv)) {
ilk_wm_get_hw_state(dev);
+   }
 
for_each_intel_crtc(dev, crtc) {
u64 put_domains;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d197617e7eeb..251794a9e5f4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1807,6 +1807,7 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
 void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
  struct skl_pipe_wm *out);
+void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
 bool intel_can_enable_sagv(struct drm_atomic_state *state);
 int intel_enable_sagv(struct drm_i915_private *dev_priv);
 int intel_disable_sagv(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5beb2d2db701..558a4e5b42b0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4713,7 +4713,6 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
 
vlv_get_fifo_size(crtc_state);
 
-   /* FIXME sanitize things more */
for (level = 0; level < active->num_levels; level++) {
struct vlv_pipe_wm *noninverted =
_state->wm.vlv.noninverted[level];
@@ -4749,6 +4748,55 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
  wm->sr.plane, wm->sr.cursor, wm->level, wm->cxsr);
 }
 
+void vlv_wm_sanitize(struct drm_i915_private *dev_priv)
+{
+   struct intel_plane *plane;
+   struct intel_crtc *crtc;
+
+   mutex_lock(_priv->wm.wm_mutex);
+
+   for_each_intel_plane(_priv->drm, plane) {
+   struct intel_crtc *crtc =
+   intel_get_crtc_for_pipe(dev_priv, plane->pipe);
+   struct intel_crtc_state *crtc_state =
+   to_intel_crtc_state(crtc->base.state);
+   struct intel_plane_state *plane_state =
+   to_intel_plane_state(plane->base.state);
+   struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
+   const struct vlv_fifo_state *fifo_state =
+   _state->wm.vlv.fifo_state;
+   enum plane_id plane_id = plane->id;
+   int level;
+
+   if (plane_state->base.visible)
+   continue;
+
+   for (level = 0; level < 

[Intel-gfx] [PATCH 08/18] drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Check whether anything relevant has actually change when we compute new
watermarks for each plane in the state. If the watermarks for no
primary/sprite planes changed we don't have to recompute the FIFO split
or reprogram the DSBARB registers. And even the cursor watermarks didn't
change we can skip the merge+invert step between all the planes on
the pipe as well.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic.c |  1 +
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_pm.c | 73 +
 3 files changed, 60 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index aa9160e7f1d8..c5d62aa24d4c 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -99,6 +99,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->update_wm_pre = false;
crtc_state->update_wm_post = false;
crtc_state->fb_changed = false;
+   crtc_state->fifo_changed = false;
crtc_state->wm.need_postvbl_update = false;
crtc_state->fb_bits = 0;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9db2548ccf6c..d7b9ddf22b3e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -568,6 +568,7 @@ struct intel_crtc_state {
bool disable_cxsr;
bool update_wm_pre, update_wm_post; /* watermarks are updated */
bool fb_changed; /* fb on any of the planes is changed */
+   bool fifo_changed; /* FIFO split is changed */
 
/* Pipe source size (ie. panel fitter input size)
 * All planes will be positioned inside this space,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cb40e5826a71..6ecad9f949c7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1115,31 +1115,36 @@ static u16 vlv_invert_wm_value(u16 wm, u16 fifo_size)
 }
 
 /* starting from 'level' set all higher levels to 'value' */
-static void vlv_plane_wm_set(struct intel_crtc_state *crtc_state,
+static bool vlv_plane_wm_set(struct intel_crtc_state *crtc_state,
 int level, enum plane_id plane_id, u16 value)
 {
struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
int num_levels = vlv_num_wm_levels(dev_priv);
+   bool dirty = false;
 
for (; level < num_levels; level++) {
struct vlv_pipe_wm *noninverted =
_state->wm.vlv.noninverted[level];
 
+   dirty |= noninverted->plane[plane_id] != value;
noninverted->plane[plane_id] = value;
}
+
+   return dirty;
 }
 
-static void vlv_plane_wm_compute(struct intel_crtc_state *crtc_state,
+static bool vlv_plane_wm_compute(struct intel_crtc_state *crtc_state,
 const struct intel_plane_state *plane_state)
 {
struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
enum plane_id plane_id = plane->id;
int num_levels = vlv_num_wm_levels(to_i915(plane->base.dev));
int level;
+   bool dirty = false;
 
if (!plane_state->base.visible) {
-   vlv_plane_wm_set(crtc_state, 0, plane_id, 0);
-   return;
+   dirty |= vlv_plane_wm_set(crtc_state, 0, plane_id, 0);
+   goto out;
}
 
for (level = 0; level < num_levels; level++) {
@@ -1155,17 +1160,22 @@ static void vlv_plane_wm_compute(struct 
intel_crtc_state *crtc_state,
if (wm > max_wm)
break;
 
+   dirty |= noninverted->plane[plane_id] != wm;
noninverted->plane[plane_id] = wm;
}
 
/* mark all higher levels as invalid */
-   vlv_plane_wm_set(crtc_state, level, plane_id, USHRT_MAX);
+   dirty |= vlv_plane_wm_set(crtc_state, level, plane_id, USHRT_MAX);
 
-   DRM_DEBUG_KMS("%s wms: [0]=%d,[1]=%d,[2]=%d\n",
- plane->base.name,
- 
crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_PM2].plane[plane_id],
- 
crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_PM5].plane[plane_id],
- 
crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_DDR_DVFS].plane[plane_id]);
+out:
+   if (dirty)
+   DRM_DEBUG_KMS("%s wms: [0]=%d,[1]=%d,[2]=%d\n",
+ plane->base.name,
+ 
crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_PM2].plane[plane_id],
+ 
crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_PM5].plane[plane_id],
+ 
crtc_state->wm.vlv.noninverted[VLV_WM_LEVEL_DDR_DVFS].plane[plane_id]);
+
+   return dirty;
 }
 
 static bool vlv_plane_wm_is_valid(const struct intel_crtc_state 

[Intel-gfx] [PATCH 11/18] drm/i915: Only use update_wm_{pre, post} for pre-ilk platforms

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Now that vlv/chv have more proper wm programming support, let's reduce
the the update_wm_{pre,post} flags to only cover the pre-ilk platforms.
When we finally convert those as well we can drop these flags entirely.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 82135101faae..a8f28e776879 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10942,21 +10942,25 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
 turn_off, turn_on, mode_changed);
 
if (turn_on) {
-   pipe_config->update_wm_pre = true;
+   if (INTEL_GEN(dev_priv) < 5)
+   pipe_config->update_wm_pre = true;
 
/* must disable cxsr around plane enable/disable */
if (plane->id != PLANE_CURSOR)
pipe_config->disable_cxsr = true;
} else if (turn_off) {
-   pipe_config->update_wm_post = true;
+   if (INTEL_GEN(dev_priv) < 5)
+   pipe_config->update_wm_post = true;
 
/* must disable cxsr around plane enable/disable */
if (plane->id != PLANE_CURSOR)
pipe_config->disable_cxsr = true;
} else if (intel_wm_need_update(>base, plane_state)) {
-   /* FIXME bollocks */
-   pipe_config->update_wm_pre = true;
-   pipe_config->update_wm_post = true;
+   if (INTEL_GEN(dev_priv) < 5) {
+   /* FIXME bollocks */
+   pipe_config->update_wm_pre = true;
+   pipe_config->update_wm_post = true;
+   }
}
 
if (visible || was_visible)
-- 
2.10.2

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


[Intel-gfx] [PATCH 05/18] drm/i915: Plop vlv/chv fifo sizes into crtc state

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Move the vlv/chv FIFO size tracking into the crtc_state. As with the wms
for now this just acts as temporary storage.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_drv.h | 11 +--
 drivers/gpu/drm/i915/intel_pm.c  | 26 +++---
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 82caf4f4a02b..493a37b089fb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -504,6 +504,10 @@ struct vlv_wm_state {
bool cxsr;
 };
 
+struct vlv_fifo_state {
+   u16 plane[I915_MAX_PLANES];
+};
+
 struct intel_crtc_wm_state {
union {
struct {
@@ -530,6 +534,7 @@ struct intel_crtc_wm_state {
} skl;
 
struct {
+   struct vlv_fifo_state fifo_state;
/* inverted optimal watermarks */
struct vlv_wm_state optimal;
} vlv;
@@ -717,10 +722,6 @@ struct intel_crtc_state {
u8 active_planes;
 };
 
-struct vlv_fifo_state {
-   uint16_t plane[I915_MAX_PLANES];
-};
-
 struct intel_crtc {
struct drm_crtc base;
enum pipe pipe;
@@ -771,8 +772,6 @@ struct intel_crtc {
 
/* allow CxSR on this pipe */
bool cxsr_allowed;
-
-   struct vlv_fifo_state fifo_state;
} wm;
 
int scanline_offset;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 507e49cd6e4a..9371b9645c9d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -405,10 +405,11 @@ static const int pessimal_latency_ns = 5000;
 #define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
dsparb) >> (lo_shift)) & 0xff) | dsparb2) >> (hi_shift)) & 0x1) 
<< 8))
 
-static void vlv_get_fifo_size(struct intel_crtc *crtc)
+static void vlv_get_fifo_size(struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct vlv_fifo_state *fifo_state = >wm.fifo_state;
+   struct vlv_fifo_state *fifo_state = _state->wm.vlv.fifo_state;
enum pipe pipe = crtc->pipe;
int sprite0_start, sprite1_start;
 
@@ -1021,7 +1022,7 @@ static void vlv_compute_fifo(struct intel_crtc_state 
*crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
-   struct vlv_fifo_state *fifo_state = >wm.fifo_state;
+   struct vlv_fifo_state *fifo_state = _state->wm.vlv.fifo_state;
struct drm_device *dev = crtc->base.dev;
struct intel_plane *plane;
unsigned int total_rate = 0;
@@ -1098,11 +1099,12 @@ static void vlv_invert_wms(struct intel_crtc_state 
*crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
+   const struct vlv_fifo_state *fifo_state =
+   _state->wm.vlv.fifo_state;
int level;
 
for (level = 0; level < wm_state->num_levels; level++) {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   const struct vlv_fifo_state *fifo_state = >wm.fifo_state;
const int sr_fifo_size =
INTEL_INFO(dev_priv)->num_pipes * 512 - 1;
enum plane_id plane_id;
@@ -1127,7 +1129,8 @@ static void vlv_compute_wm(struct intel_crtc_state 
*crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
-   const struct vlv_fifo_state *fifo_state = >wm.fifo_state;
+   const struct vlv_fifo_state *fifo_state =
+   _state->wm.vlv.fifo_state;
struct intel_plane *plane;
int level;
 
@@ -1196,10 +1199,12 @@ static void vlv_compute_wm(struct intel_crtc_state 
*crtc_state)
 #define VLV_FIFO(plane, value) \
(((value) << DSPARB_ ## plane ## _SHIFT_VLV) & DSPARB_ ## plane ## 
_MASK_VLV)
 
-static void vlv_pipe_set_fifo_size(struct intel_crtc *crtc)
+static void vlv_pipe_set_fifo_size(const struct intel_crtc_state *crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   const struct vlv_fifo_state *fifo_state = >wm.fifo_state;
+   const struct vlv_fifo_state *fifo_state =
+   _state->wm.vlv.fifo_state;
int sprite0_start, sprite1_start, fifo_size;
 
sprite0_start = fifo_state->plane[PLANE_PRIMARY];
@@ -1350,8 +1355,7 @@ static void vlv_update_wm(struct intel_crtc *crtc)
 
if 

[Intel-gfx] [PATCH 10/18] drm/i915: Nuke crtc->wm.cxsr_allowed

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Remove crtc->wm.cxsr_allowed and just rely on crtc_state->disable_cxsr
instead. This was used only by vlv/chv to indicate whether to enable
cxsr in the wm computation. That doesn't really work anymore, and as far
as the optimal watermarks go we'll just consider the number of planes
and the current pipe, and for the intermediate watermarks we'll also
start to consider disable_cxsr which is set appropriately when planes
are being enabled/disabled.

We'll also flip over the crtc_state->wm.need_postvbl_update setup so
that it's the wm code that will set it. Previously the generic code set
it up, and then the wm code cleared it again if it thought it's not
needed after all.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 44 +++-
 drivers/gpu/drm/i915/intel_drv.h |  3 ---
 drivers/gpu/drm/i915/intel_pm.c  | 14 ++--
 3 files changed, 20 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 77160eaa2294..82135101faae 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5002,8 +5002,6 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
 
intel_frontbuffer_flip(to_i915(crtc->base.dev), pipe_config->fb_bits);
 
-   crtc->wm.cxsr_allowed = true;
-
if (pipe_config->update_wm_post && pipe_config->base.active)
intel_update_watermarks(crtc);
 
@@ -5050,22 +5048,18 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
intel_pre_disable_primary(>base);
}
 
-   if (pipe_config->disable_cxsr && HAS_GMCH_DISPLAY(dev_priv)) {
-   crtc->wm.cxsr_allowed = false;
-
-   /*
-* Vblank time updates from the shadow to live plane control 
register
-* are blocked if the memory self-refresh mode is active at that
-* moment. So to make sure the plane gets truly disabled, 
disable
-* first the self-refresh mode. The self-refresh enable bit in 
turn
-* will be checked/applied by the HW only at the next frame 
start
-* event which is after the vblank start event, so we need to 
have a
-* wait-for-vblank between disabling the plane and the pipe.
-*/
-   if (old_crtc_state->base.active &&
-   intel_set_memory_cxsr(dev_priv, false))
-   intel_wait_for_vblank(dev_priv, crtc->pipe);
-   }
+   /*
+* Vblank time updates from the shadow to live plane control register
+* are blocked if the memory self-refresh mode is active at that
+* moment. So to make sure the plane gets truly disabled, disable
+* first the self-refresh mode. The self-refresh enable bit in turn
+* will be checked/applied by the HW only at the next frame start
+* event which is after the vblank start event, so we need to have a
+* wait-for-vblank between disabling the plane and the pipe.
+*/
+   if (HAS_GMCH_DISPLAY(dev_priv) && old_crtc_state->base.active &&
+   pipe_config->disable_cxsr && intel_set_memory_cxsr(dev_priv, false))
+   intel_wait_for_vblank(dev_priv, crtc->pipe);
 
/*
 * IVB workaround: must disable low power watermarks for at least
@@ -10965,11 +10959,6 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
pipe_config->update_wm_post = true;
}
 
-   /* Pre-gen9 platforms need two-step watermark updates */
-   if ((pipe_config->update_wm_pre || pipe_config->update_wm_post) &&
-   INTEL_GEN(dev_priv) < 9 && dev_priv->display.optimize_watermarks)
-   to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
-
if (visible || was_visible)
pipe_config->fb_bits |= plane->frontbuffer_bit;
 
@@ -12713,12 +12702,7 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
if (crtc_state->update_wm_post)
return true;
 
-   /*
-* cxsr is re-enabled after vblank.
-* This is already handled by crtc_state->update_wm_post,
-* but added for clarity.
-*/
-   if (crtc_state->disable_cxsr)
+   if (crtc_state->wm.need_postvbl_update)
return true;
 
return false;
@@ -13970,8 +13954,6 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
intel_crtc->cursor_cntl = ~0;
intel_crtc->cursor_size = ~0;
 
-   intel_crtc->wm.cxsr_allowed = true;
-
/* initialize shared scalers */
intel_crtc_init_scalers(intel_crtc, crtc_state);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 

[Intel-gfx] [PATCH 01/18] drm/i915: Track visible planes in a bitmask

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

In a lot of place we wish to know which planes on the crtc are actually
visible, or how many of them there are. Let's start tracking that in a
bitmask in the crtc state.

We already track enabled planes (ie. ones with an fb and crtc specified by
the user) but that's not quite the same thing as enabled planes may
still end up being invisible due to clipping and whatnot.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  6 +++
 drivers/gpu/drm/i915/intel_display.c  | 74 +--
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 3 files changed, 60 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 41fd94e62d3c..1eaf840cf9ff 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -189,6 +189,12 @@ int intel_plane_atomic_check_with_state(struct 
intel_crtc_state *crtc_state,
if (ret)
return ret;
 
+   /* FIXME pre-g4x don't work like this */
+   if (intel_state->base.visible)
+   crtc_state->active_planes |= BIT(intel_plane->id);
+   else
+   crtc_state->active_planes &= ~BIT(intel_plane->id);
+
return intel_plane_atomic_calc_changes(_state->base, state);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0d46a8db5c6f..0ccc04607b8a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2674,6 +2674,29 @@ update_state_fb(struct drm_plane *plane)
 }
 
 static void
+intel_set_plane_visible(struct intel_crtc_state *crtc_state,
+   struct intel_plane_state *plane_state,
+   bool visible)
+{
+   struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
+
+   plane_state->base.visible = visible;
+
+   /* FIXME pre-g4x don't work like this */
+   if (visible) {
+   crtc_state->base.plane_mask |= 
BIT(drm_plane_index(>base));
+   crtc_state->active_planes |= BIT(plane->id);
+   } else {
+   crtc_state->base.plane_mask &= 
~BIT(drm_plane_index(>base));
+   crtc_state->active_planes &= ~BIT(plane->id);
+   }
+
+   DRM_DEBUG_KMS("%s active planes 0x%x\n",
+ crtc_state->base.crtc->name,
+ crtc_state->active_planes);
+}
+
+static void
 intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
 struct intel_initial_plane_config *plane_config)
 {
@@ -2730,8 +2753,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
 * simplest solution is to just disable the primary plane now and
 * pretend the BIOS never had it enabled.
 */
-   plane_state->visible = false;
-   crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
+   intel_set_plane_visible(to_intel_crtc_state(crtc_state),
+   to_intel_plane_state(plane_state),
+   false);
intel_pre_disable_primary_noatomic(_crtc->base);
intel_plane->disable_plane(primary, _crtc->base);
 
@@ -2771,7 +2795,11 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
drm_framebuffer_reference(fb);
primary->fb = primary->state->fb = fb;
primary->crtc = primary->state->crtc = _crtc->base;
-   intel_crtc->base.state->plane_mask |= (1 << drm_plane_index(primary));
+
+   intel_set_plane_visible(to_intel_crtc_state(crtc_state),
+   to_intel_plane_state(plane_state),
+   true);
+
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
  >frontbuffer_bits);
 }
@@ -10853,11 +10881,11 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc_state);
struct drm_crtc *crtc = crtc_state->crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_plane *plane = plane_state->plane;
+   struct intel_plane *plane = to_intel_plane(plane_state->plane);
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_plane_state *old_plane_state =
-   to_intel_plane_state(plane->state);
+   to_intel_plane_state(plane->base.state);
bool mode_changed = needs_modeset(crtc_state);
bool was_crtc_enabled = crtc->state->active;
bool is_crtc_enabled = crtc_state->active;
@@ -10865,7 +10893,7 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
struct drm_framebuffer *fb = plane_state->fb;
int ret;
 
-   if (INTEL_GEN(dev_priv) >= 9 && plane->type != DRM_PLANE_TYPE_CURSOR) {
+   if 

[Intel-gfx] [PATCH 09/18] drm/i915: Compute proper intermediate wms for vlv/cvh

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Since the watermark registers arent double buffered on VLV/CHV, we'll
need to play around with intermediate watermarks same was as we do on
ILK-BDW.

The watermark registers on VLV/CHV contain inverted values, so to find
the intermediate watermark value we just take the minimum of the
active and optimal values. This also means that, unlike ILK-BDW,
there's no chance that we'd fail to find a working intermediate
watermarks. As long as both the active and optimal watermarks are valid
the intermediate watermarks will come out valid as well.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_drv.h |  3 +-
 drivers/gpu/drm/i915/intel_pm.c  | 59 +++-
 2 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7b9ddf22b3e..1c31100482ef 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -535,7 +535,8 @@ struct intel_crtc_wm_state {
/* non-inverted optimal watermarks */
struct vlv_pipe_wm noninverted[NUM_VLV_WM_LEVELS];
struct vlv_fifo_state fifo_state;
-   /* inverted optimal watermarks */
+   /* inverted intermediate and optimal watermarks */
+   struct vlv_wm_state intermediate;
struct vlv_wm_state optimal;
} vlv;
};
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6ecad9f949c7..ec384d559aae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1391,6 +1391,45 @@ static void vlv_atomic_update_fifo(struct 
intel_atomic_state *state,
 
 #undef VLV_FIFO
 
+static int vlv_compute_intermediate_wm(struct drm_device *dev,
+  struct intel_crtc *crtc,
+  struct intel_crtc_state *crtc_state)
+{
+   struct vlv_wm_state *intermediate = _state->wm.vlv.intermediate;
+   const struct vlv_wm_state *optimal = _state->wm.vlv.optimal;
+   const struct vlv_wm_state *active = >wm.active.vlv;
+   int level;
+
+   intermediate->num_levels = min(optimal->num_levels, active->num_levels);
+   intermediate->cxsr = optimal->cxsr & active->cxsr;
+
+   for (level = 0; level < intermediate->num_levels; level++) {
+   enum plane_id plane_id;
+
+   for_each_plane_id_on_crtc(crtc, plane_id) {
+   intermediate->wm[level].plane[plane_id] =
+   min(optimal->wm[level].plane[plane_id],
+   active->wm[level].plane[plane_id]);
+   }
+
+   intermediate->sr[level].plane = min(optimal->sr[level].plane,
+   active->sr[level].plane);
+   intermediate->sr[level].cursor = min(optimal->sr[level].cursor,
+active->sr[level].cursor);
+   }
+
+   vlv_invalidate_wms(crtc, intermediate, level);
+
+   /*
+* If our intermediate WM are identical to the final WM, then we can
+* omit the post-vblank programming; only update if it's different.
+*/
+   if (memcmp(intermediate, optimal, sizeof(*intermediate)) == 0)
+   crtc_state->wm.need_postvbl_update = false;
+
+   return 0;
+}
+
 static void vlv_merge_wm(struct drm_i915_private *dev_priv,
 struct vlv_wm_values *wm)
 {
@@ -1484,7 +1523,22 @@ static void vlv_initial_watermarks(struct 
intel_atomic_state *state,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
 
mutex_lock(_priv->wm.wm_mutex);
-   crtc->wm.active.vlv = crtc_state->wm.vlv.optimal;
+   crtc->wm.active.vlv = crtc_state->wm.vlv.intermediate;
+   vlv_program_watermarks(dev_priv);
+   mutex_unlock(_priv->wm.wm_mutex);
+}
+
+static void vlv_optimize_watermarks(struct intel_atomic_state *state,
+   struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
+
+   if (!crtc_state->wm.need_postvbl_update)
+   return;
+
+   mutex_lock(_priv->wm.wm_mutex);
+   intel_crtc->wm.active.vlv = crtc_state->wm.vlv.optimal;
vlv_program_watermarks(dev_priv);
mutex_unlock(_priv->wm.wm_mutex);
 }
@@ -4681,6 +4735,7 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
vlv_invalidate_wms(crtc, active, level);
 
crtc_state->wm.vlv.optimal = *active;
+   crtc_state->wm.vlv.intermediate = *active;
 
DRM_DEBUG_KMS("Initial watermarks: pipe %c, plane=%d, 
cursor=%d, 

[Intel-gfx] [PATCH 06/18] drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Let's compute the watermarks first and the FIFO size second. This way we
can make sure the FIFO split is the most accommodating to the watermarks.
Previously we could have potentially computed a FIFO split that couldn't
accommodate the PM2 watermarks simply due to a bad split even if the
total FIFO size would have been sufficient.

It'll also allow us to avoid recomputing the wms for all planes whenever
the FIFO split would change. Thus we don't have to add any extra planes
to the state when the FIFO needs to be repartitioned.

To help with this we'll keep around copies of the non-inverted
watermarks in the crtc state. For now that doesn't help too much, but
once we start to do the watermark computation only for the planes
that change we'll need the non-inverted values around for the other
planes.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 116 +++
 2 files changed, 57 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 493a37b089fb..ada5fd3fdeab 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -534,6 +534,8 @@ struct intel_crtc_wm_state {
} skl;
 
struct {
+   /* non-inverted optimal watermarks */
+   struct vlv_pipe_wm noninverted[NUM_VLV_WM_LEVELS];
struct vlv_fifo_state fifo_state;
/* inverted optimal watermarks */
struct vlv_wm_state optimal;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9371b9645c9d..ad02edb11ca2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1018,73 +1018,70 @@ static uint16_t vlv_compute_wm_level(const struct 
intel_crtc_state *crtc_state,
return min_t(int, wm, USHRT_MAX);
 }
 
-static void vlv_compute_fifo(struct intel_crtc_state *crtc_state)
+static int vlv_compute_fifo(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
-   struct vlv_wm_state *wm_state = _state->wm.vlv.optimal;
+   const struct vlv_pipe_wm *noninverted =
+   _state->wm.vlv.noninverted[VLV_WM_LEVEL_PM2];
struct vlv_fifo_state *fifo_state = _state->wm.vlv.fifo_state;
-   struct drm_device *dev = crtc->base.dev;
-   struct intel_plane *plane;
-   unsigned int total_rate = 0;
-   const int fifo_size = 512 - 1;
+   unsigned int active_planes = crtc_state->active_planes & 
~BIT(PLANE_CURSOR);
+   int num_active_planes = hweight32(active_planes);
+   const int fifo_size = 511;
int fifo_extra, fifo_left = fifo_size;
+   unsigned int total_rate;
+   enum plane_id plane_id;
 
-   for_each_intel_plane_on_crtc(dev, crtc, plane) {
-   struct intel_plane_state *state =
-   to_intel_plane_state(plane->base.state);
+   total_rate = noninverted->plane[PLANE_PRIMARY] +
+   noninverted->plane[PLANE_SPRITE0] +
+   noninverted->plane[PLANE_SPRITE1];
 
-   if (plane->id == PLANE_CURSOR)
-   continue;
+   if (total_rate > fifo_size)
+   return -EINVAL;
 
-   if (state->base.visible) {
-   wm_state->num_active_planes++;
-   total_rate += state->base.fb->format->cpp[0];
-   }
-   }
+   if (total_rate == 0)
+   total_rate = 1;
 
-   for_each_intel_plane_on_crtc(dev, crtc, plane) {
-   struct intel_plane_state *state =
-   to_intel_plane_state(plane->base.state);
+   for_each_plane_id_on_crtc(crtc, plane_id) {
unsigned int rate;
 
-   if (plane->id == PLANE_CURSOR) {
-   fifo_state->plane[plane->id] = 63;
+   if ((active_planes & BIT(plane_id)) == 0) {
+   fifo_state->plane[plane_id] = 0;
continue;
}
 
-   if (!state->base.visible) {
-   fifo_state->plane[plane->id] = 0;
-   continue;
-   }
-
-   rate = state->base.fb->format->cpp[0];
-   fifo_state->plane[plane->id] = fifo_size * rate / total_rate;
-   fifo_left -= fifo_state->plane[plane->id];
+   rate = noninverted->plane[plane_id];
+   fifo_state->plane[plane_id] = fifo_size * rate / total_rate;
+   fifo_left -= fifo_state->plane[plane_id];
}
 
-   fifo_extra = DIV_ROUND_UP(fifo_left, wm_state->num_active_planes ?: 1);
+   fifo_state->plane[PLANE_CURSOR] = 63;
+
+   

[Intel-gfx] [PATCH 03/18] drm/i915: Move vlv wms from crtc->wm_state to crtc->wm.active.vlv

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

In an effort to make the vlv/chv wm code look and behave more like the
ilk+ code, let's move the current active wms next to the
corresponding ilk wms.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_drv.h |  3 +--
 drivers/gpu/drm/i915/intel_pm.c  | 10 +-
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6ee05b0404a..f4ba686e3e22 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -754,6 +754,7 @@ struct intel_crtc {
/* watermarks currently being used  */
union {
struct intel_pipe_wm ilk;
+   struct vlv_wm_state vlv;
} active;
 
/* allow CxSR on this pipe */
@@ -773,8 +774,6 @@ struct intel_crtc {
 
/* scalers available on this crtc */
int num_scalers;
-
-   struct vlv_wm_state wm_state;
 };
 
 struct intel_plane {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 06826945576e..b29b05a195d8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1025,7 +1025,7 @@ static uint16_t vlv_compute_wm_level(const struct 
intel_crtc_state *crtc_state,
 
 static void vlv_compute_fifo(struct intel_crtc *crtc)
 {
-   struct vlv_wm_state *wm_state = >wm_state;
+   struct vlv_wm_state *wm_state = >wm.active.vlv;
struct vlv_fifo_state *fifo_state = >wm.fifo_state;
struct drm_device *dev = crtc->base.dev;
struct intel_plane *plane;
@@ -1101,7 +1101,7 @@ static u16 vlv_invert_wm_value(u16 wm, u16 fifo_size)
 
 static void vlv_invert_wms(struct intel_crtc *crtc)
 {
-   struct vlv_wm_state *wm_state = >wm_state;
+   struct vlv_wm_state *wm_state = >wm.active.vlv;
int level;
 
for (level = 0; level < wm_state->num_levels; level++) {
@@ -1129,7 +1129,7 @@ static void vlv_invert_wms(struct intel_crtc *crtc)
 static void vlv_compute_wm(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct vlv_wm_state *wm_state = >wm_state;
+   struct vlv_wm_state *wm_state = >wm.active.vlv;
const struct vlv_fifo_state *fifo_state = >wm.fifo_state;
struct intel_plane *plane;
int level;
@@ -1292,7 +1292,7 @@ static void vlv_merge_wm(struct drm_i915_private 
*dev_priv,
wm->cxsr = true;
 
for_each_intel_crtc(_priv->drm, crtc) {
-   const struct vlv_wm_state *wm_state = >wm_state;
+   const struct vlv_wm_state *wm_state = >wm.active.vlv;
 
if (!crtc->active)
continue;
@@ -1311,7 +1311,7 @@ static void vlv_merge_wm(struct drm_i915_private 
*dev_priv,
wm->level = VLV_WM_LEVEL_PM2;
 
for_each_intel_crtc(_priv->drm, crtc) {
-   struct vlv_wm_state *wm_state = >wm_state;
+   const struct vlv_wm_state *wm_state = >wm.active.vlv;
enum pipe pipe = crtc->pipe;
 
if (!crtc->active)
-- 
2.10.2

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


[Intel-gfx] [PATCH v2 00/18] drm/i915: VLV/CHV two-stage watermarks (v2)

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

A rebased version of the two stage watermark support for VLV/CHV. Mostly
just cosmetic changes due to churn. I did clear out that unused
intel_plane_wm_parameters structure Maarten pointed out.

The sticking point in the last series was the active_planes bitmask, but
I've decided to leave that as is because it was the most convenient way
to do it for VLV/CHV, and I think it should work quite well for g4x as
well (which is something I want to tackle after landing this stuff).
I might still change my mind when I get down to gen2-gen4 territory
but until I really start on that I don't want to needlessly change
directions.

Oh one new thing I added here is cleaned up versions of some the
tracepoints I used in debugging this stuff. I think those would
be usedful to have upstream so I've included them in the series.

Entire series is available here:
git://github.com/vsyrjala/linux.git vlv_atomic_wm_6

Ville Syrjälä (18):
  drm/i915: Track visible planes in a bitmask
  drm/i915: Track plane fifo sizes under intel_crtc
  drm/i915: Move vlv wms from crtc->wm_state to crtc->wm.active.vlv
  drm/i915: Plop vlv wm state into crtc_state
  drm/i915: Plop vlv/chv fifo sizes into crtc state
  drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks
  drm/i915: Compute vlv/chv wms the atomic way
  drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not
needed
  drm/i915: Compute proper intermediate wms for vlv/cvh
  drm/i915: Nuke crtc->wm.cxsr_allowed
  drm/i915: Only use update_wm_{pre,post} for pre-ilk platforms
  drm/i915: Sanitize VLV/CHV watermarks properly
  drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun
  drm/i915: Kill level 0 wm hack for VLV/CHV
  drm/i915: Add plane update/disable tracepoints
  drm/i915: Add VLV/CHV watermark/FIFO programming tracepoints
  drm/i915: Add cxsr toggle tracepoint
  drm/i915: Add FIFO underrun tracepoints

 drivers/gpu/drm/i915/i915_drv.h|   8 +
 drivers/gpu/drm/i915/i915_irq.c|   3 +
 drivers/gpu/drm/i915/i915_trace.h  | 200 +
 drivers/gpu/drm/i915/intel_atomic.c|   1 +
 drivers/gpu/drm/i915/intel_atomic_plane.c  |  17 +-
 drivers/gpu/drm/i915/intel_display.c   | 179 +---
 drivers/gpu/drm/i915/intel_drv.h   |  71 ++-
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  11 +-
 drivers/gpu/drm/i915/intel_pm.c| 668 -
 9 files changed, 836 insertions(+), 322 deletions(-)

-- 
2.10.2

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


Re: [Intel-gfx] [PATCH] drm/i915: Defer declaration of missed-interrupt until the waiter is asleep

2017-02-16 Thread kbuild test robot
Hi Chris,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.10-rc8 next-20170216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Defer-declaration-of-missed-interrupt-until-the-waiter-is-asleep/20170217-013743
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x008-201707 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_breadcrumbs.c: In function 
'intel_breadcrumbs_hangcheck':
>> drivers/gpu/drm/i915/intel_breadcrumbs.c:47:28: error: implicit declaration 
>> of function 'wait_timeout' [-Werror=implicit-function-declaration]
  mod_timer(>hangcheck, wait_timeout());
   ^~~~
   drivers/gpu/drm/i915/intel_breadcrumbs.c: At top level:
>> drivers/gpu/drm/i915/intel_breadcrumbs.c:67:22: error: conflicting types for 
>> 'wait_timeout'
static unsigned long wait_timeout(void)
 ^~~~
   drivers/gpu/drm/i915/intel_breadcrumbs.c:47:28: note: previous implicit 
declaration of 'wait_timeout' was here
  mod_timer(>hangcheck, wait_timeout());
   ^~~~
   cc1: some warnings being treated as errors

vim +/wait_timeout +47 drivers/gpu/drm/i915/intel_breadcrumbs.c

41  
42  /* If the waiter was currently running, assume it hasn't had a 
chance
43   * to process the pending interupt (e.g, low priority task on a 
loaded
44   * system) and wait until it sleeps before declaring a missed 
interrupt.
45   */
46  if (!intel_engine_wakeup(engine)) {
  > 47  mod_timer(>hangcheck, wait_timeout());
48  return;
49  }
50  
51  DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
52  set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
53  mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
54  
55  /* Ensure that even if the GPU hangs, we get woken up.
56   *
57   * However, note that if no one is waiting, we never notice
58   * a gpu hang. Eventually, we will have to wait for a resource
59   * held by the GPU and so trigger a hangcheck. In the most
60   * pathological case, this will be upon memory starvation! To
61   * prevent this, we also queue the hangcheck from the retire
62   * worker.
63   */
64  i915_queue_hangcheck(engine->i915);
65  }
66  
  > 67  static unsigned long wait_timeout(void)
68  {
69  return round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES);
70  }

---
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


Re: [Intel-gfx] [PATCH] ALSA: x86: Fix spinlock usage in the trigger callback

2017-02-16 Thread Takashi Iwai
On Thu, 16 Feb 2017 15:46:16 +0100,
Ville Syrjälä wrote:
> 
> On Wed, Feb 15, 2017 at 10:21:08PM +0100, Takashi Iwai wrote:
> > On Wed, 15 Feb 2017 20:15:50 +0100,
> > ville.syrj...@linux.intel.com wrote:
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > Simply doing 'xset dpms force off' while playback is active seems
> > > sufficient to anger lockdep [1]. And it's of course correct that it's
> > > not safe to use regular spin_lock() outside the irq handler when
> > > the irq handler also wants to acquire the same lock. I believe the
> > > trigger callback can get called from both irq and non-irq context,
> > > so we need to to use spin_lock_irqsave() & co. here.
> > 
> > No, it's just because I used snd_pcm_stop() wrongly.  A proper fix
> > patch is already in the queue I'm going to submit right now:
> >   [PATCH 2/8] ALSA: x86: Use snd_pcm_stop_xrun() for connection /
> > disconnection paths
> 
> OK, cool. I'll have to try this again once I see that land somewhere.

FYI, I merged the branch now to for-next, so it should be included in
linux-next tomorrow.


thanks,

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


Re: [Intel-gfx] [PATCH 08/14] drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed

2017-02-16 Thread Ville Syrjälä
On Thu, Dec 15, 2016 at 04:37:53PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä 
> >
> > Check whether anything relevant has actually change when we compute new
> > watermarks for each plane in the state. If the watermarks for no
> > primary/sprite planes changed we don't have to recompute the FIFO split
> > or reprogram the DSBARB registers. And even the cursor watermarks didn't
> > change we can skip the merge+invert step between all the planes on
> > the pipe as well.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_atomic.c |  1 +
> >  drivers/gpu/drm/i915/intel_drv.h|  1 +
> >  drivers/gpu/drm/i915/intel_pm.c | 73 
> > +
> >  3 files changed, 60 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index c5a166752eda..df33f270b459 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -99,6 +99,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > crtc_state->update_wm_pre = false;
> > crtc_state->update_wm_post = false;
> > crtc_state->fb_changed = false;
> > +   crtc_state->fifo_changed = false;
> > crtc_state->wm.need_postvbl_update = false;
> > crtc_state->fb_bits = 0;
> This flag is only used in intel_pm.c, maybe put it in 
> crtc_state->wm.vlv.fifo_changed, and clear it in the beginning of the wm 
> recalculation?

I don't really like that. The state we get from duplicate_state() should
be directly useable IMO. It was already checked after all. So all these
kinds of flags should be reset immediately I think.

I guess modeset is a bit of an exception to my logic there. That is I'm
forcing the flag back to true wheever there's a modeset. Alternatively
I could restore the registers whenever the power well gets turned back
on, but this way is a little simpler I think.

> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 8c18a47a..a92857864ee8 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -560,6 +560,7 @@ struct intel_crtc_state {
> > bool disable_cxsr;
> > bool update_wm_pre, update_wm_post; /* watermarks are updated */
> > bool fb_changed; /* fb on any of the planes is changed */
> > +   bool fifo_changed; /* FIFO split is changed */
> >  
> > /* Pipe source size (ie. panel fitter input size)
> >  * All planes will be positioned inside this space,
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index f68b46eed224..c7cc62cf51f6 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -1103,31 +1103,36 @@ static u16 vlv_invert_wm_value(u16 wm, u16 
> > fifo_size)
> >  }
> >  
> >  /* starting from 'level' set all higher levels to 'value' */
> > -static void vlv_plane_wm_set(struct intel_crtc_state *crtc_state,
> > +static bool vlv_plane_wm_set(struct intel_crtc_state *crtc_state,
> >  int level, enum plane_id plane_id, u16 value)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> > int num_levels = vlv_num_wm_levels(dev_priv);
> > +   bool dirty = false;
> >  
> > for (; level < num_levels; level++) {
> > struct vlv_pipe_wm *noninverted =
> > _state->wm.vlv.noninverted[level];
> >  
> > +   dirty |= noninverted->plane[plane_id] != value;
> > noninverted->plane[plane_id] = value;
> > }
> > +
> > +   return dirty;
> >  }
> >  
> > -static void vlv_plane_wm_compute(struct intel_crtc_state *crtc_state,
> > +static bool vlv_plane_wm_compute(struct intel_crtc_state *crtc_state,
> >  const struct intel_plane_state *plane_state)
> >  {
> > struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > enum plane_id plane_id = plane->id;
> > int num_levels = vlv_num_wm_levels(to_i915(plane->base.dev));
> > int level;
> > +   bool dirty = false;
> >  
> > if (!plane_state->base.visible) {
> > -   vlv_plane_wm_set(crtc_state, 0, plane_id, 0);
> > -   return;
> > +   dirty |= vlv_plane_wm_set(crtc_state, 0, plane_id, 0);
> > +   goto out;
> > }
> >  
> > for (level = 0; level < num_levels; level++) {
> > @@ -1143,17 +1148,22 @@ static void vlv_plane_wm_compute(struct 
> > intel_crtc_state *crtc_state,
> > if (wm > max_wm)
> > break;
> >  
> > +   dirty |= noninverted->plane[plane_id] != wm;
> > noninverted->plane[plane_id] = wm;
> > }
> >  
> > /* mark all higher levels as invalid */
> > -   vlv_plane_wm_set(crtc_state, level, plane_id, USHRT_MAX);
> > +   dirty |= 

Re: [Intel-gfx] [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

2017-02-16 Thread Jani Nikula
On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
>> Handle debugfs override edid and firmware edid at the low level to
>> transparently and completely replace the real edid. Previously, we
>> practically only used the modes from the override EDID, and none of the
>> other data. This also prevents actual EDID reads when the EDID is to be
>> overridden, but retains the DDC probe.
>
> Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
> somethign then the override EDID wouldn't be returned by drm_get_edid().

Isn't this in line with how this currently works?

BR,
Jani.


>
>> 
>> FIXME: validate override edid, deduplicate firmware edid validation.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_edid.c | 15 +++
>>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
>>  2 files changed, 16 insertions(+), 18 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 362036360724..054e2d74eafc 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
>> *connector,
>>   * level, drivers must make all reasonable efforts to expose it as an I2C
>>   * adapter and use drm_get_edid() instead of abusing this function.
>>   *
>> + * The EDID may be overridden using debugfs override_edid or firmare EDID
>> + * (drm_load_edid_firmware()), in this priority order. Having either of them
>> + * bypasses actual EDID reads.
>> + *
>>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
>>   */
>>  struct edid *drm_do_get_edid(struct drm_connector *connector,
>> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
>> *connector,
>>  {
>>  int i, j = 0, valid_extensions = 0;
>>  u8 *edid, *new;
>> +struct edid *override = NULL;
>> +
>> +if (connector->override_edid)
>> +override = drm_edid_duplicate((const struct edid *)
>> +  connector->edid_blob_ptr->data);
>> +
>> +if (!override)
>> +override = drm_load_edid_firmware(connector);
>> +
>> +if (!IS_ERR_OR_NULL(override))
>> +return override;
>>  
>>  if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>>  return NULL;
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index 358957118ca9..871326cbc465 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
>> bool force)
>>   *drm_mode_probed_add(). New modes start their life with status as OK.
>>   *Modes are added from a single source using the following priority 
>> order.
>>   *
>> - *- debugfs 'override_edid' (used for testing only)
>> - *- firmware EDID (drm_load_edid_firmware())
>>   *- _connector_helper_funcs.get_modes vfunc
>>   *- if the connector status is connector_status_connected, standard
>>   *  VESA DMT modes up to 1024x768 are automatically added
>> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
>> drm_connector *connector,
>>  goto prune;
>>  }
>>  
>> -if (connector->override_edid) {
>> -struct edid *edid = (struct edid *) 
>> connector->edid_blob_ptr->data;
>> -
>> -count = drm_add_edid_modes(connector, edid);
>> -drm_edid_to_eld(connector, edid);
>> -} else {
>> -struct edid *edid = drm_load_edid_firmware(connector);
>> -if (!IS_ERR_OR_NULL(edid)) {
>> -drm_mode_connector_update_edid_property(connector, 
>> edid);
>> -count = drm_add_edid_modes(connector, edid);
>> -drm_edid_to_eld(connector, edid);
>> -kfree(edid);
>> -}
>> -if (count == 0)
>> -count = (*connector_funcs->get_modes)(connector);
>> -}
>> +count = (*connector_funcs->get_modes)(connector);
>>  
>>  if (count == 0 && connector->status == connector_status_connected)
>>  count = drm_add_modes_noedid(connector, 1024, 768);
>> -- 
>> 2.1.4

-- 
Jani Nikula, 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 02/14] drm/i915: Track plane fifo sizes under intel_crtc

2017-02-16 Thread Ville Syrjälä
On Thu, Dec 15, 2016 at 03:58:44PM +0100, Maarten Lankhorst wrote:
> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä 
> >
> > Track the plane fifo sizes under intel_crtc instead of under each
> > intel_plane. Avoids looping over the planes in a bunch of places,
> > and later we'll move this tracking into the crtc state properly.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |   7 ++-
> >  drivers/gpu/drm/i915/intel_pm.c  | 115 
> > ---
> >  2 files changed, 54 insertions(+), 68 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 20ba8f48bc3b..69b6f45e3eed 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -683,6 +683,10 @@ struct vlv_wm_state {
> > bool cxsr;
> >  };
> >  
> > +struct vlv_fifo_state {
> > +   uint16_t plane[I915_MAX_PLANES];
> > +};
> > +
> >  struct intel_crtc {
> > struct drm_crtc base;
> > enum pipe pipe;
> > @@ -732,6 +736,8 @@ struct intel_crtc {
> >  
> > /* allow CxSR on this pipe */
> > bool cxsr_allowed;
> > +
> > +   struct vlv_fifo_state fifo_state;
> > } wm;
> >  
> > int scanline_offset;
> > @@ -765,7 +771,6 @@ struct intel_plane_wm_parameters {
> > bool scaled;
> > u64 tiling;
> > unsigned int rotation;
> > -   uint16_t fifo_size;
> >  };
> intel_plane_wm_parameters can be removed entirely, fifo_size was the only 
> member still being used there.

Done.

-- 
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: Perform link quality check unconditionally during long pulse

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 09:24:09AM -0800, Manasi Navare wrote:
> On Thu, Feb 16, 2017 at 07:18:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 16, 2017 at 09:07:53AM -0800, Manasi Navare wrote:
> > > On Thu, Feb 16, 2017 at 05:30:07PM +0200, ville.syrj...@linux.intel.com 
> > > wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Apparently some DP sinks are a little nuts and cause HPD to drop
> > > > intermittently during modesets. This happens eg. on an ASUS PB287Q.
> > > > In oder to recover from this we can't really use the previous
> > > > connector status to determine if the link needs retraining, so let's
> > > > just ignore that piece of information and do the retrain
> > > > unconditionally. We do of course still check whether the link is
> > > > supposed to be running or not.
> > > > 
> > > > Cc: sta...@vger.kernel.org
> > > > Cc: Palmer Dabbelt 
> > > > Reported-by: Palmer Dabbelt 
> > > > References: 
> > > > https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
> > > > Signed-off-by: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 15 +++
> > > >  1 file changed, 11 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 024798a9c016..37a746f7fbc3 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
> > > > *intel_connector)
> > > >  */
> > > > status = connector_status_disconnected;
> > > > goto out;
> > > > -   } else if (connector->status == connector_status_connected) {
> > > > +   } else {
> > > > /*
> > > > -* If display was connected already and is still 
> > > > connected
> > > > -* check links status, there has been known issues of
> > > > -* link loss triggerring long pulse
> > > > +* If display is now connected check links status,
> > > > +* there has been known issues of link loss triggerring
> > > > +* long pulse.
> > > > +*
> > > > +* Some sinks (eg. ASUS PB287Q) seem to perform some
> > > > +* weird HPD ping pong during modesets. So we can 
> > > > apparely
> > > > +* end up with HPD going low during a modeset, and then
> > > > +* going back up soon after. And once that happens we 
> > > > must
> > > > +* retrain the link to get a picture. That's in case no
> > > > +* userspace component reacted to intermittent HPD dip.
> > > >  */
> > > > drm_modeset_lock(>mode_config.connection_mutex, 
> > > > NULL);
> > > > intel_dp_check_link_status(intel_dp);
> > > > --
> > > 
> > > So here we basically just ignore the connector status and retrain 
> > > irrespectively.
> > 
> > We ignore the _previous_ connector status.
> > 
> > > But that means even if we have newer values now for max link rate/lane 
> > > count from
> > > DPCD, during this retrain we are just using the stale value of 
> > > intel_dp->link_rate
> > > and intel_dp->lane_count. I think intel_dp->link_rate and lane count 
> > > values
> > > should be set to 0 on HPD pulse, they would be set only during a modeset.
> > 
> > The DPCD has already been parsed by this time.
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> 
> Yes, we have parsed the DPCD but we dont write to intel_dp->link-rate and 
> intel_dp->lane_count
> until we do a modeset (these get written during pre_enable) and these values 
> get used
> during the retraining of the link. So at this point we will still use stale 
> values.

They're not stale. They're exactly what we used when we set up the
mode that's still being drive out. This is just retraining the link
at the same parameters.

> Shouldnt we set the link status to BAD and send a hotplug event, like the 
> solution we implemneted
> for retraining?
> 
> Regards
> Manasi
> 
> Regards
> Manasi

-- 
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: Perform link quality check unconditionally during long pulse

2017-02-16 Thread Manasi Navare
On Thu, Feb 16, 2017 at 07:18:57PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 16, 2017 at 09:07:53AM -0800, Manasi Navare wrote:
> > On Thu, Feb 16, 2017 at 05:30:07PM +0200, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Apparently some DP sinks are a little nuts and cause HPD to drop
> > > intermittently during modesets. This happens eg. on an ASUS PB287Q.
> > > In oder to recover from this we can't really use the previous
> > > connector status to determine if the link needs retraining, so let's
> > > just ignore that piece of information and do the retrain
> > > unconditionally. We do of course still check whether the link is
> > > supposed to be running or not.
> > > 
> > > Cc: sta...@vger.kernel.org
> > > Cc: Palmer Dabbelt 
> > > Reported-by: Palmer Dabbelt 
> > > References: 
> > > https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 15 +++
> > >  1 file changed, 11 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 024798a9c016..37a746f7fbc3 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
> > > *intel_connector)
> > >*/
> > >   status = connector_status_disconnected;
> > >   goto out;
> > > - } else if (connector->status == connector_status_connected) {
> > > + } else {
> > >   /*
> > > -  * If display was connected already and is still connected
> > > -  * check links status, there has been known issues of
> > > -  * link loss triggerring long pulse
> > > +  * If display is now connected check links status,
> > > +  * there has been known issues of link loss triggerring
> > > +  * long pulse.
> > > +  *
> > > +  * Some sinks (eg. ASUS PB287Q) seem to perform some
> > > +  * weird HPD ping pong during modesets. So we can apparely
> > > +  * end up with HPD going low during a modeset, and then
> > > +  * going back up soon after. And once that happens we must
> > > +  * retrain the link to get a picture. That's in case no
> > > +  * userspace component reacted to intermittent HPD dip.
> > >*/
> > >   drm_modeset_lock(>mode_config.connection_mutex, NULL);
> > >   intel_dp_check_link_status(intel_dp);
> > > --
> > 
> > So here we basically just ignore the connector status and retrain 
> > irrespectively.
> 
> We ignore the _previous_ connector status.
> 
> > But that means even if we have newer values now for max link rate/lane 
> > count from
> > DPCD, during this retrain we are just using the stale value of 
> > intel_dp->link_rate
> > and intel_dp->lane_count. I think intel_dp->link_rate and lane count values
> > should be set to 0 on HPD pulse, they would be set only during a modeset.
> 
> The DPCD has already been parsed by this time.
> 
> -- 
> Ville Syrjälä
> Intel OTC

Yes, we have parsed the DPCD but we dont write to intel_dp->link-rate and 
intel_dp->lane_count
until we do a modeset (these get written during pre_enable) and these values 
get used
during the retraining of the link. So at this point we will still use stale 
values.
Shouldnt we set the link status to BAD and send a hotplug event, like the 
solution we implemneted
for retraining?

Regards
Manasi

Regards
Manasi
___
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: Squelch any ktime/jiffie rounding errors for wait-ioctl

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl
URL   : https://patchwork.freedesktop.org/series/19780/
State : success

== Summary ==

Series 19780v1 drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl
https://patchwork.freedesktop.org/api/1.0/series/19780/revisions/1/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

b29710e319e4b58d994065f5e776f6f66674d7c9 drm-tip: 2017y-02m-16d-15h-35m-40s UTC 
integration manifest
c891169 drm/i915: Squelch any ktime/jiffie rounding errors for wait-ioctl

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3856/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Perform link quality check unconditionally during long pulse

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 09:07:53AM -0800, Manasi Navare wrote:
> On Thu, Feb 16, 2017 at 05:30:07PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Apparently some DP sinks are a little nuts and cause HPD to drop
> > intermittently during modesets. This happens eg. on an ASUS PB287Q.
> > In oder to recover from this we can't really use the previous
> > connector status to determine if the link needs retraining, so let's
> > just ignore that piece of information and do the retrain
> > unconditionally. We do of course still check whether the link is
> > supposed to be running or not.
> > 
> > Cc: sta...@vger.kernel.org
> > Cc: Palmer Dabbelt 
> > Reported-by: Palmer Dabbelt 
> > References: 
> > https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 15 +++
> >  1 file changed, 11 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 024798a9c016..37a746f7fbc3 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
> > *intel_connector)
> >  */
> > status = connector_status_disconnected;
> > goto out;
> > -   } else if (connector->status == connector_status_connected) {
> > +   } else {
> > /*
> > -* If display was connected already and is still connected
> > -* check links status, there has been known issues of
> > -* link loss triggerring long pulse
> > +* If display is now connected check links status,
> > +* there has been known issues of link loss triggerring
> > +* long pulse.
> > +*
> > +* Some sinks (eg. ASUS PB287Q) seem to perform some
> > +* weird HPD ping pong during modesets. So we can apparely
> > +* end up with HPD going low during a modeset, and then
> > +* going back up soon after. And once that happens we must
> > +* retrain the link to get a picture. That's in case no
> > +* userspace component reacted to intermittent HPD dip.
> >  */
> > drm_modeset_lock(>mode_config.connection_mutex, NULL);
> > intel_dp_check_link_status(intel_dp);
> > --
> 
> So here we basically just ignore the connector status and retrain 
> irrespectively.

We ignore the _previous_ connector status.

> But that means even if we have newer values now for max link rate/lane count 
> from
> DPCD, during this retrain we are just using the stale value of 
> intel_dp->link_rate
> and intel_dp->lane_count. I think intel_dp->link_rate and lane count values
> should be set to 0 on HPD pulse, they would be set only during a modeset.

The DPCD has already been parsed by this time.

-- 
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: Perform link quality check unconditionally during long pulse

2017-02-16 Thread Manasi Navare
On Thu, Feb 16, 2017 at 05:30:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Apparently some DP sinks are a little nuts and cause HPD to drop
> intermittently during modesets. This happens eg. on an ASUS PB287Q.
> In oder to recover from this we can't really use the previous
> connector status to determine if the link needs retraining, so let's
> just ignore that piece of information and do the retrain
> unconditionally. We do of course still check whether the link is
> supposed to be running or not.
> 
> Cc: sta...@vger.kernel.org
> Cc: Palmer Dabbelt 
> Reported-by: Palmer Dabbelt 
> References: 
> https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 024798a9c016..37a746f7fbc3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>*/
>   status = connector_status_disconnected;
>   goto out;
> - } else if (connector->status == connector_status_connected) {
> + } else {
>   /*
> -  * If display was connected already and is still connected
> -  * check links status, there has been known issues of
> -  * link loss triggerring long pulse
> +  * If display is now connected check links status,
> +  * there has been known issues of link loss triggerring
> +  * long pulse.
> +  *
> +  * Some sinks (eg. ASUS PB287Q) seem to perform some
> +  * weird HPD ping pong during modesets. So we can apparely
> +  * end up with HPD going low during a modeset, and then
> +  * going back up soon after. And once that happens we must
> +  * retrain the link to get a picture. That's in case no
> +  * userspace component reacted to intermittent HPD dip.
>*/
>   drm_modeset_lock(>mode_config.connection_mutex, NULL);
>   intel_dp_check_link_status(intel_dp);
> --

So here we basically just ignore the connector status and retrain 
irrespectively.
But that means even if we have newer values now for max link rate/lane count 
from
DPCD, during this retrain we are just using the stale value of 
intel_dp->link_rate
and intel_dp->lane_count. I think intel_dp->link_rate and lane count values
should be set to 0 on HPD pulse, they would be set only during a modeset.

Regards
Manasi

 
> 2.10.2
> 
> ___
> 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] i915: Dealing with 90° rotated display ?

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 15-02-17 15:59, Ville Syrjälä wrote:
> > On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
> >> Hi Jani,
> >>
> >> As discussed here:
> >>
> >> https://bugs.freedesktop.org/show_bug.cgi?id=94894
> >>
> >> I've a mini-laptop which uses a phone-screen,
> >> so the native orientation of the screen is portrait,
> >> where as for a clam-shell device one wants it to
> >> be landscape. Ideally there would be a flag somewhere
> >> to tell the i915 driver that the panel is mounted
> >> 90° rotated in its bezel and have the i915 driver
> >> apply that rotation on top of whatever rotation
> >> userspace requests.
> >>
> >> So question is there already a place (variable) in
> >> the i915 driver where one can set such a rotation
> >> offset to apply on top of what userspace requests ?
> >>
> >> If not do you have any idea how feasible adding one
> >> would be and can you give me a few pointers / hints
> >> where to start with such a thing ?
> >
> > You could have a look at my branch (which I pointed out in the bug).
> 
> Ok, so the patch that actually is relevant to this
> discussion (and not just a cleanup / bug-fix) seems to be:
> 
> https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e
> 
> Right ?

Looks that way, yes.

> 
> AFAICT that will make fbcon inherit the rotation setting of
> the primary plan on the primary crt. That may solve the
> original bug as reported, but not the case / device I'm
> talking about. What I would like to see is a "rotation offset"
> field somewhere to be applied to all rotations in a way which
> is hidden from userspace. Specifically the device I've has a
> screen which is 720x1280 in resolution, but I want userspace
> to see it as a 1280x720 screen because that is how it is used
> in the hardware. So I want a 90° rotation to be applied which
> is completely hidden from userspace.

That's not necessarily the best way since rotation may impose
additional restrictions on what the hardware can do. Which would
mean that your 0 degree setting would no longer be the setting
that should give the highest chance of success. That doesn't leave
much chance of userspace being able to work out a fallback strategy
when things don't succeed.

Oh, and the cursor plane can't even do 90/270 degree rotation, so
there's just no way to hide this fully.

That said, I did once implement a "full pipe rotation" thing, and even
added a knob into debugfs that allowed me to flip it without userspace
being involved. That's just something I used for testing the rotation
code initially. I just pushed some version of it here [1]. Obviously
90/270 effective rotation for the cursor still won't work.

[1] git://github.com/vsyrjala/linux.git full_pipe_rotation

> So when userspace
> (e.g. the Xorg server + modesetting driver) asks for 0° degree
> rotation under the hood they get 90 applied, when they aks for
> the panel resolution they get 1280x720 instead of 720x1280.

The idea was that userspace will inherit the initial rotation.
That does work correctly at least with the intel ddx. Given that our
rotation properties are per-plane, that would mean userspace would have
to deduce that the entire screen is rotation by simply looking at the
rotation of the primary plane. Or I suppose we could make the kernel
use the same default rotation for all planes, even the disabled ines.

> 
> Basically the idea is that the kernel as the HAL it is supposed
> to be (amongst other things) hide the hardware weirdness / quirk
> of using a portrait panel in a landscape bezel.

As said we can't really hide without causing additional grief to
userspace in the form of potential failures in configuring the
planes/crtcs.

-- 
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: success for Moving the common engine/ring code to intel_engine_cs.c (rev2)

2017-02-16 Thread Patchwork
== Series Details ==

Series: Moving the common engine/ring code to intel_engine_cs.c (rev2)
URL   : https://patchwork.freedesktop.org/series/19706/
State : success

== Summary ==

Series 19706v2 Moving the common engine/ring code to intel_engine_cs.c
https://patchwork.freedesktop.org/api/1.0/series/19706/revisions/2/mbox/

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

b29710e319e4b58d994065f5e776f6f66674d7c9 drm-tip: 2017y-02m-16d-15h-35m-40s UTC 
integration manifest
0ab5237 drm/i915: Simplify cleanup path in intel_engines_init
326aab8 drm/i915: Move common workaround code to intel_engine_cs
e58add4 drm/i915: Make int __intel_ring_space static

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3855/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm/i915: Take forcewake for setting the RPS thresholds

2017-02-16 Thread Chris Wilson
Take forcewake for the entire duration of reprogramming the RPS
thresholds. By itself it should not achieve much as instead of going
into the FIFO, we force the device to wake for the reprograming, but it
should help in regards to the next patch that introduces a read.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_pm.c | 44 +++--
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d603c1e03560..135d00185488 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4869,25 +4869,31 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
break;
}
 
-   I915_WRITE(GEN6_RP_UP_EI,
-  GT_INTERVAL_FROM_US(dev_priv, ei_up));
-   I915_WRITE(GEN6_RP_UP_THRESHOLD,
-  GT_INTERVAL_FROM_US(dev_priv,
-  ei_up * threshold_up / 100));
-
-   I915_WRITE(GEN6_RP_DOWN_EI,
-  GT_INTERVAL_FROM_US(dev_priv, ei_down));
-   I915_WRITE(GEN6_RP_DOWN_THRESHOLD,
-  GT_INTERVAL_FROM_US(dev_priv,
-  ei_down * threshold_down / 100));
-
-   I915_WRITE(GEN6_RP_CONTROL,
-  GEN6_RP_MEDIA_TURBO |
-  GEN6_RP_MEDIA_HW_NORMAL_MODE |
-  GEN6_RP_MEDIA_IS_GFX |
-  GEN6_RP_ENABLE |
-  GEN6_RP_UP_BUSY_AVG |
-  GEN6_RP_DOWN_IDLE_AVG);
+   spin_lock_irq(_priv->uncore.lock);
+   intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
+
+   I915_WRITE_FW(GEN6_RP_UP_EI,
+ GT_INTERVAL_FROM_US(dev_priv, ei_up));
+   I915_WRITE_FW(GEN6_RP_UP_THRESHOLD,
+ GT_INTERVAL_FROM_US(dev_priv,
+ ei_up * threshold_up / 100));
+
+   I915_WRITE_FW(GEN6_RP_DOWN_EI,
+ GT_INTERVAL_FROM_US(dev_priv, ei_down));
+   I915_WRITE_FW(GEN6_RP_DOWN_THRESHOLD,
+ GT_INTERVAL_FROM_US(dev_priv,
+ ei_down * threshold_down / 100));
+
+   I915_WRITE_FW(GEN6_RP_CONTROL,
+ GEN6_RP_MEDIA_TURBO |
+ GEN6_RP_MEDIA_HW_NORMAL_MODE |
+ GEN6_RP_MEDIA_IS_GFX |
+ GEN6_RP_ENABLE |
+ GEN6_RP_UP_BUSY_AVG |
+ GEN6_RP_DOWN_IDLE_AVG);
+
+   intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
+   spin_unlock_irq(_priv->uncore.lock);
 
dev_priv->rps.power = new_power;
dev_priv->rps.up_threshold = threshold_up;
-- 
2.11.0

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


[Intel-gfx] [PATCH 2/2] drm/i915: Restart RPS using the same RP_CONTROL as from initialisation

2017-02-16 Thread Chris Wilson
During initialisation, we set different flags for different
architectures - these should be preserved when we reload the RPS
thresholds. If we use a mmio read, it will first ensure that the
threshold registers are written before we apply the latch in RP_CONTROL.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_pm.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 096bc7a6ebde..31ee7db8e26c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4884,13 +4884,8 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
  GT_INTERVAL_FROM_US(dev_priv,
  ei_down * threshold_down / 100));
 
-   I915_WRITE_FW(GEN6_RP_CONTROL,
- GEN6_RP_MEDIA_TURBO |
- GEN6_RP_MEDIA_HW_NORMAL_MODE |
- GEN6_RP_MEDIA_IS_GFX |
- GEN6_RP_ENABLE |
- GEN6_RP_UP_BUSY_AVG |
- GEN6_RP_DOWN_IDLE_AVG);
+   /* Restart RPS to reload the thresholds */
+   I915_WRITE_FW(GEN6_RP_CONTROL, I915_READ_FW(GEN6_RP_CONTROL));
 
intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
spin_unlock_irq(_priv->uncore.lock);
-- 
2.11.0

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


[Intel-gfx] [PATCH 1/2] drm/i915: Take forcewake for setting the RPS thresholds

2017-02-16 Thread Chris Wilson
Take forcewake for the entire duration of reprogramming the RPS
thresholds. By itself it should not achieve much as instead of going
into the FIFO, we force the device to wake for the reprograming, but it
should help in regards to the next patch that introduces a read.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_pm.c | 44 +++--
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d603c1e03560..096bc7a6ebde 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4869,25 +4869,31 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
break;
}
 
-   I915_WRITE(GEN6_RP_UP_EI,
-  GT_INTERVAL_FROM_US(dev_priv, ei_up));
-   I915_WRITE(GEN6_RP_UP_THRESHOLD,
-  GT_INTERVAL_FROM_US(dev_priv,
-  ei_up * threshold_up / 100));
-
-   I915_WRITE(GEN6_RP_DOWN_EI,
-  GT_INTERVAL_FROM_US(dev_priv, ei_down));
-   I915_WRITE(GEN6_RP_DOWN_THRESHOLD,
-  GT_INTERVAL_FROM_US(dev_priv,
-  ei_down * threshold_down / 100));
-
-   I915_WRITE(GEN6_RP_CONTROL,
-  GEN6_RP_MEDIA_TURBO |
-  GEN6_RP_MEDIA_HW_NORMAL_MODE |
-  GEN6_RP_MEDIA_IS_GFX |
-  GEN6_RP_ENABLE |
-  GEN6_RP_UP_BUSY_AVG |
-  GEN6_RP_DOWN_IDLE_AVG);
+   spin_unlock_irq(_priv->uncore.lock);
+   intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
+
+   I915_WRITE_FW(GEN6_RP_UP_EI,
+ GT_INTERVAL_FROM_US(dev_priv, ei_up));
+   I915_WRITE_FW(GEN6_RP_UP_THRESHOLD,
+ GT_INTERVAL_FROM_US(dev_priv,
+ ei_up * threshold_up / 100));
+
+   I915_WRITE_FW(GEN6_RP_DOWN_EI,
+ GT_INTERVAL_FROM_US(dev_priv, ei_down));
+   I915_WRITE_FW(GEN6_RP_DOWN_THRESHOLD,
+ GT_INTERVAL_FROM_US(dev_priv,
+ ei_down * threshold_down / 100));
+
+   I915_WRITE_FW(GEN6_RP_CONTROL,
+ GEN6_RP_MEDIA_TURBO |
+ GEN6_RP_MEDIA_HW_NORMAL_MODE |
+ GEN6_RP_MEDIA_IS_GFX |
+ GEN6_RP_ENABLE |
+ GEN6_RP_UP_BUSY_AVG |
+ GEN6_RP_DOWN_IDLE_AVG);
+
+   intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
+   spin_unlock_irq(_priv->uncore.lock);
 
dev_priv->rps.power = new_power;
dev_priv->rps.up_threshold = threshold_up;
-- 
2.11.0

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


Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

2017-02-16 Thread Daniele Ceraolo Spurio



On 15/02/17 23:44, Chris Wilson wrote:

On Wed, Feb 15, 2017 at 06:28:59PM -0800, Daniele Ceraolo Spurio wrote:

On 14/02/17 05:53, Joonas Lahtinen wrote:

-static void guc_disable_doorbell(struct intel_guc *guc,
-struct i915_guc_client *client)
+static int __destroy_doorbell(struct i915_guc_client *client)
{
-   (void)guc_update_doorbell_id(guc, client, GUC_INVALID_DOORBELL_ID);
+   struct guc_doorbell_info *doorbell;

-   /* XXX: wait for any interrupts */
-   /* XXX: wait for workqueue to drain */
+   doorbell = __get_doorbell(client);
+   doorbell->db_status = GUC_DOORBELL_DISABLED;
+   doorbell->cookie = 0;
+


Not from this patch (but since we're at it...), I did a bit of
digging and I've found that doorbell release flow requires SW to
poll the GEN8_DRBREGL(db_id) register after updating
doorbell->db_status to wait for the GEN8_DRB_VALID bit to go to
zero. This ensures that any pending events are processed before we
call into GuC to release the doorbell. Note that GuC will fail the
DEALLOCATE_DOORBELL action if the bit has not gone to zero yet. This
is currently not an issue, probably because we use a single doorbell
and we don't ring it near release time, but the situation could
change in the future so I believe it is worth to fix it now. I can
follow up with an additional patch if you want to keep this one as
refactoring only.


Just keep in mind that we currently do a disable after GPU reset. The guc
may not know what we are talking about :)
-Chris



Yep, we should move the release to before reset or, if the 
client/doorbell page stays pinned across reset, limit ourselves to just 
updating the db status in memory (which will cause the validity bit to 
be updated accordingly) without notifying GuC, because as you said GuC 
will have no idea of what we're referring to.


I'm also seeing a doorbell release failure during driver unload:

[drm] INTEL_GUC_SEND: Action 0x20 failed; ret=-110 status=0x0020 
response=0x


I haven't looked int it yet (I was waiting for this patch to go in 
first), but when I reload the driver the status of the doorbells seems 
to be ok so probably just a communication issue with GuC.


Thanks,
Daniele
___
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 GLK MIPI DSI VIDEO MODE PATCHES (rev5)

2017-02-16 Thread Chauhan, Madhav
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, February 16, 2017 8:49 PM
> To: Patchwork ; Chauhan, Madhav
> 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE
> PATCHES (rev5)
> 
> On Tue, 14 Feb 2017, Patchwork 
> wrote:
> > drivers/gpu/drm/i915/intel_dsi_pll.c: In function ‘intel_compute_dsi_pll’:
> > drivers/gpu/drm/i915/intel_dsi_pll.c:513:45: error: ‘dsi_ratio_max’ may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
> >   if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
> >  ^
> > drivers/gpu/drm/i915/intel_dsi_pll.c:492:31: note: ‘dsi_ratio_max’ was
> declared here
> >   u8 dsi_ratio, dsi_ratio_min, dsi_ratio_max;
> >^
> >   LD  drivers/tty/serial/built-in.o
> >   LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
> > cc1: all warnings being treated as errors
> > scripts/Makefile.build:294: recipe for target
> > 'drivers/gpu/drm/i915/intel_dsi_pll.o' failed
> > make[4]: *** [drivers/gpu/drm/i915/intel_dsi_pll.o] Error 1
> > make[4]: *** Waiting for unfinished jobs
> 
> The series didn't get tested because of this. Please update the series and
> repost, and do remember to add the Reviewed-by tags to the patches I've
> reviewed so far.

Agree. Surprised to see why I didn’t get this error during compilation in my 
local environment. Used x86_64_defconfig. Any idea ??

> 
> Thanks,
> Jani.
> 
> 
> 
> --
> Jani Nikula, 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: Perform link quality check unconditionally during long pulse

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 07:39:29AM -0800, Palmer Dabbelt wrote:
> On Thu, 16 Feb 2017 07:30:07 PST (-0800), ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Apparently some DP sinks are a little nuts and cause HPD to drop
> > intermittently during modesets. This happens eg. on an ASUS PB287Q.
> > In oder to recover from this we can't really use the previous
> > connector status to determine if the link needs retraining, so let's
> > just ignore that piece of information and do the retrain
> > unconditionally. We do of course still check whether the link is
> > supposed to be running or not.
> 
> With this patch on top of linux-4.9 I have DPMS on/off working again, but I
> don't have the correct resolutions on my monitor.  I just see
> 
> DP1 connected 1024x768+2880+0 (normal left inverted right x axis y axis) 0mm 
> x 0mm
>1024x768  60.00*
>800x600   60.3256.25
>848x480   60.00
>640x480   59.94

Hmm. That would indicate that the EDID reads are also failing now.
I wonder if your monitor is just a lemon.

Anyways, there were no failed EDID reads visible in the logs you
provided. You should keep the drm.debug=0xe and rerun xrandr (do not
use the --current knob), and then we should check the dmesg again
to see what the kernel thinks the mode list should look like.

> 
> >
> > Cc: sta...@vger.kernel.org
> > Cc: Palmer Dabbelt 
> > Reported-by: Palmer Dabbelt 
> > References: 
> > https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 15 +++
> >  1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 024798a9c016..37a746f7fbc3 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
> > *intel_connector)
> >  */
> > status = connector_status_disconnected;
> > goto out;
> > -   } else if (connector->status == connector_status_connected) {
> > +   } else {
> > /*
> > -* If display was connected already and is still connected
> > -* check links status, there has been known issues of
> > -* link loss triggerring long pulse
> > +* If display is now connected check links status,
> > +* there has been known issues of link loss triggerring
> > +* long pulse.
> > +*
> > +* Some sinks (eg. ASUS PB287Q) seem to perform some
> > +* weird HPD ping pong during modesets. So we can apparely
> > +* end up with HPD going low during a modeset, and then
> > +* going back up soon after. And once that happens we must
> > +* retrain the link to get a picture. That's in case no
> > +* userspace component reacted to intermittent HPD dip.
> >  */
> > drm_modeset_lock(>mode_config.connection_mutex, NULL);
> > intel_dp_check_link_status(intel_dp);

-- 
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 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
> Handle debugfs override edid and firmware edid at the low level to
> transparently and completely replace the real edid. Previously, we
> practically only used the modes from the override EDID, and none of the
> other data. This also prevents actual EDID reads when the EDID is to be
> overridden, but retains the DDC probe.

Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
somethign then the override EDID wouldn't be returned by drm_get_edid().

> 
> FIXME: validate override edid, deduplicate firmware edid validation.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 15 +++
>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
>  2 files changed, 16 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 362036360724..054e2d74eafc 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>   * level, drivers must make all reasonable efforts to expose it as an I2C
>   * adapter and use drm_get_edid() instead of abusing this function.
>   *
> + * The EDID may be overridden using debugfs override_edid or firmare EDID
> + * (drm_load_edid_firmware()), in this priority order. Having either of them
> + * bypasses actual EDID reads.
> + *
>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
>   */
>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
>  {
>   int i, j = 0, valid_extensions = 0;
>   u8 *edid, *new;
> + struct edid *override = NULL;
> +
> + if (connector->override_edid)
> + override = drm_edid_duplicate((const struct edid *)
> +   connector->edid_blob_ptr->data);
> +
> + if (!override)
> + override = drm_load_edid_firmware(connector);
> +
> + if (!IS_ERR_OR_NULL(override))
> + return override;
>  
>   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>   return NULL;
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 358957118ca9..871326cbc465 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
> bool force)
>   *drm_mode_probed_add(). New modes start their life with status as OK.
>   *Modes are added from a single source using the following priority 
> order.
>   *
> - *- debugfs 'override_edid' (used for testing only)
> - *- firmware EDID (drm_load_edid_firmware())
>   *- _connector_helper_funcs.get_modes vfunc
>   *- if the connector status is connector_status_connected, standard
>   *  VESA DMT modes up to 1024x768 are automatically added
> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   goto prune;
>   }
>  
> - if (connector->override_edid) {
> - struct edid *edid = (struct edid *) 
> connector->edid_blob_ptr->data;
> -
> - count = drm_add_edid_modes(connector, edid);
> - drm_edid_to_eld(connector, edid);
> - } else {
> - struct edid *edid = drm_load_edid_firmware(connector);
> - if (!IS_ERR_OR_NULL(edid)) {
> - drm_mode_connector_update_edid_property(connector, 
> edid);
> - count = drm_add_edid_modes(connector, edid);
> - drm_edid_to_eld(connector, edid);
> - kfree(edid);
> - }
> - if (count == 0)
> - count = (*connector_funcs->get_modes)(connector);
> - }
> + count = (*connector_funcs->get_modes)(connector);
>  
>   if (count == 0 && connector->status == connector_status_connected)
>   count = drm_add_modes_noedid(connector, 1024, 768);
> -- 
> 2.1.4

-- 
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: Perform link quality check unconditionally during long pulse

2017-02-16 Thread Palmer Dabbelt
On Thu, 16 Feb 2017 07:30:07 PST (-0800), ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Apparently some DP sinks are a little nuts and cause HPD to drop
> intermittently during modesets. This happens eg. on an ASUS PB287Q.
> In oder to recover from this we can't really use the previous
> connector status to determine if the link needs retraining, so let's
> just ignore that piece of information and do the retrain
> unconditionally. We do of course still check whether the link is
> supposed to be running or not.

With this patch on top of linux-4.9 I have DPMS on/off working again, but I
don't have the correct resolutions on my monitor.  I just see

DP1 connected 1024x768+2880+0 (normal left inverted right x axis y axis) 0mm x 
0mm
   1024x768  60.00*
   800x600   60.3256.25
   848x480   60.00
   640x480   59.94

>
> Cc: sta...@vger.kernel.org
> Cc: Palmer Dabbelt 
> Reported-by: Palmer Dabbelt 
> References: 
> https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 024798a9c016..37a746f7fbc3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>*/
>   status = connector_status_disconnected;
>   goto out;
> - } else if (connector->status == connector_status_connected) {
> + } else {
>   /*
> -  * If display was connected already and is still connected
> -  * check links status, there has been known issues of
> -  * link loss triggerring long pulse
> +  * If display is now connected check links status,
> +  * there has been known issues of link loss triggerring
> +  * long pulse.
> +  *
> +  * Some sinks (eg. ASUS PB287Q) seem to perform some
> +  * weird HPD ping pong during modesets. So we can apparely
> +  * end up with HPD going low during a modeset, and then
> +  * going back up soon after. And once that happens we must
> +  * retrain the link to get a picture. That's in case no
> +  * userspace component reacted to intermittent HPD dip.
>*/
>   drm_modeset_lock(>mode_config.connection_mutex, NULL);
>   intel_dp_check_link_status(intel_dp);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/3] drm: reset ELD if NULL edid is passed to drm_edid_to_eld

2017-02-16 Thread Ville Syrjälä
On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote:
> Make the function useful for resetting, not just setting, the ELD.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 24e7b282f16c..362036360724 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3430,6 +3430,9 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>  
>   memset(eld, 0, sizeof(connector->eld));
>  
> + if (!edid)
> + return;
> +
>   connector->latency_present[0] = false;
>   connector->latency_present[1] = false;
>   connector->video_latency[0] = 0;

/me thinks the check should be after all these.

Hmm. Actually the cea ext block check below should be safe wrt.
edid==NULL, so not sure we need this at all.

-- 
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/glk: CDCLK calculation changes for glk

2017-02-16 Thread Jani Nikula
On Thu, 16 Feb 2017, Madhav Chauhan  wrote:
> As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
> Practically we can achive only 99% of these cdclk values(HW team
> checking on this). So cdclk should be calculated for the given pixclk as
> per that otherwise it may lead to screen corruption for some scenarios.
>
> v2: Rebased to new CDLCK code framework
>
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index d643c0c..834df68 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1071,9 +1071,9 @@ static int bxt_calc_cdclk(int max_pixclk)
>  
>  static int glk_calc_cdclk(int max_pixclk)
>  {
> - if (max_pixclk > 2 * 158400)
> + if (max_pixclk > DIV_ROUND_UP(2 * 158400 * 99, 100))

Where do we ensure we don't use pixel clock 312841..316800? Clearly we
shouldn't use that because we can't guarantee it works, right?

Before we get the spec update to confirm what to do, I think we need a
comment here explaining what's going on.

BR,
Jani.

>   return 316800;
> - else if (max_pixclk > 2 * 79200)
> + else if (max_pixclk > DIV_ROUND_UP(2 * 79200 * 99, 100))
>   return 158400;
>   else
>   return 79200;

-- 
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] [PATCH] drm/i915: Defer declaration of missed-interrupt until the waiter is asleep

2017-02-16 Thread Chris Wilson
If the waiter was currently running, assume it hasn't had a chance
to process the pending interupt (e.g, low priority task on a loaded
system) and wait until it sleeps before declaring a missed interrupt.

References: https://bugs.freedesktop.org/show_bug.cgi?id=99816
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 4395b177493e..2ad29fb77b2d 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -45,6 +45,15 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
return;
}
 
+   /* If the waiter was currently running, assume it hasn't had a chance
+* to process the pending interupt (e.g, low priority task on a loaded
+* system) and wait until it sleeps before declaring a missed interrupt.
+*/
+   if (!intel_engine_wakeup(engine)) {
+   mod_timer(>hangcheck, wait_timeout());
+   return;
+   }
+
DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
-- 
2.11.0

___
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: Unwind conversion to i915_gem_phys_ops on failure (rev2)

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm/i915: Unwind conversion to i915_gem_phys_ops on failure (rev2)
URL   : https://patchwork.freedesktop.org/series/19708/
State : failure

== Summary ==

Series 19708v2 drm/i915: Unwind conversion to i915_gem_phys_ops on failure
https://patchwork.freedesktop.org/api/1.0/series/19708/revisions/2/mbox/

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> INCOMPLETE (fi-hsw-4770r)

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:225  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:249  pass:233  dwarn:0   dfail:0   fail:0   skip:15 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:224  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:252  pass:223  dwarn:0   dfail:0   fail:0   skip:29 

89a932d98b6e1733011019c9872583a9c7c8fda3 drm-tip: 2017y-02m-16d-10h-06m-42s UTC 
integration manifest
445b36b drm/i915: Unwind conversion to i915_gem_phys_ops on failure

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3854/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Perform link quality check unconditionally during long pulse

2017-02-16 Thread ville . syrjala
From: Ville Syrjälä 

Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.

Cc: sta...@vger.kernel.org
Cc: Palmer Dabbelt 
Reported-by: Palmer Dabbelt 
References: 
https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 024798a9c016..37a746f7fbc3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
 */
status = connector_status_disconnected;
goto out;
-   } else if (connector->status == connector_status_connected) {
+   } else {
/*
-* If display was connected already and is still connected
-* check links status, there has been known issues of
-* link loss triggerring long pulse
+* If display is now connected check links status,
+* there has been known issues of link loss triggerring
+* long pulse.
+*
+* Some sinks (eg. ASUS PB287Q) seem to perform some
+* weird HPD ping pong during modesets. So we can apparely
+* end up with HPD going low during a modeset, and then
+* going back up soon after. And once that happens we must
+* retrain the link to get a picture. That's in case no
+* userspace component reacted to intermittent HPD dip.
 */
drm_modeset_lock(>mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
-- 
2.10.2

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


Re: [Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug

2017-02-16 Thread Ville Syrjälä
On Wed, Feb 15, 2017 at 06:58:13PM -0800, Palmer Dabbelt wrote:
> On Tue, Feb 14, 2017 at 11:00 AM, Ville Syrjälä
>  wrote:
> > On Tue, Feb 14, 2017 at 10:48:10AM -0800, Palmer Dabbelt wrote:
> >> On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrj...@linux.intel.com 
> >> wrote:
> >> > On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote:
> >> >> DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro
> >> >> attached to an ASUS PB287Q).  I believe the problem is that long pulses
> >> >> are no longer triggering intel_dp_check_link_status.
> >> >
> >> > That shouldn't itsefl cause problems with hotplugs. It could cause
> >> > problems if you hotplug displays without a proper randr client running
> >> > in which case the link is left running when you unplug the displays and
> >> > then gets retrained when you plug a display back in.
> >>
> >> Maybe it's a problem with my setup, as I don't think I have any randr 
> >> client
> >> running: I just run xrandr via my xinitrc and via some scripts linked from 
> >> udev
> >> for DRM hotplug events for when I move the laptop around.
> >
> > That should more or less work. Well, depends on what you do in your
> > udev scripts. But that's pretty much what your typical xrandr clients
> > do, except the udev event gets first converted into a randr event by the
> > X server.
> >
> >> Is it required that
> >> I have more stuff running in order to make DPMS events work?
> >
> > Not sure what you mean by DPMS events. "xset dpms" just turns things
> > on/off, there are no events involved really.
> 
> I guess my "dpms event" I meant "the monitor going on and off".
> 
> >> IIRC my setup has
> >> looked like this for years now, but if it's broken because it's wacky then 
> >> I
> >> can change it.
> >>
> >> Regardless, I think something is still broken here.  I don't need to 
> >> actaully
> >> unplug anything for this to break, if I just run "xset dpms force off" to 
> >> turn
> >> the screen off and then wake it back up my eDP laptop display comes back 
> >> fine
> >> but my DP monitor doesn't.
> >
> > That is definitely a bug somewhere. Can you boot your machine with
> > drm.debug=0xe passed to the kernel, then reproduce this dpms problem,
> > and then post the full dmesg. Maybe the log will show something
> > interesting.
> 
> Attached.  There's two copies: one from after I boot and start X, and
> the second from after I do a DPMS cycle:
> 
>   $ xset dpms force off
>   $ sleep 10s # wait for the monitor to go to sleep
>   # press ctrl to wake the monitor back up
> 
> One item of interest: when I ran this on my work monitor (a newer Dell
> DisplayPort monitor) I didn't have any DPMS problems, but when I ran
> it on my ASUS PB287Q the monitor doesn't come back from sleep.

[   94.812227] [drm:intel_enable_pipe] enabling pipe B
[   94.812237] [drm:intel_audio_codec_enable] ELD on [CONNECTOR:45:DP-1], 
[ENCODER:44:DDI B]
[   94.812240] [drm:hsw_audio_codec_enable] Enable audio codec on pipe B, 36 
bytes ELD
[   94.856356] [drm:verify_connector_state] [CONNECTOR:45:DP-1]
[   94.856365] [drm:intel_atomic_commit_tail] [CRTC:30:pipe B]
[   94.856377] [drm:verify_single_dpll_state.isra.113] LCPLL 2700
[   95.343061] [drm:intel_get_hpd_pins] hotplug event received, stat 
0x0020, dig 0x00101012, pins 0x0020
[   95.343067] [drm:intel_hpd_irq_handler] digital hpd port B - long
[   95.343069] [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 5 - 
cnt: 0
[   95.343102] [drm:intel_dp_hpd_pulse] got hpd irq on port B - long
[   95.343108] [drm:i915_hotplug_work_func] running encoder hotplug functions
[   95.343112] [drm:i915_hotplug_work_func] Connector DP-1 (pin 5) received 
hotplug event.
[   95.343114] [drm:intel_dp_detect] [CONNECTOR:45:DP-1]
[   95.343130] [drm:i915_hotplug_work_func] [CONNECTOR:45:DP-1] status updated 
from connected to disconnected

OK so here turned on the pipe, and soon after the sink decided
to drop HPD for some reason.

[   96.545016] [drm:intel_get_hpd_pins] hotplug event received, stat 
0x0020, dig 0x00101012, pins 0x0020
[   96.545023] [drm:intel_hpd_irq_handler] digital hpd port B - long
[   96.545026] [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 5 - 
cnt: 0
[   96.545059] [drm:intel_dp_hpd_pulse] got hpd irq on port B - long
[   96.545067] [drm:i915_hotplug_work_func] running encoder hotplug functions
[   96.545070] [drm:i915_hotplug_work_func] Connector DP-1 (pin 5) received 
hotplug event.
[   96.545076] [drm:intel_dp_detect] [CONNECTOR:45:DP-1]
[   96.546859] [drm:intel_dp_read_dpcd] DPCD: 12 14 c4 01 01 00 01 00 02 02 06 
00 00 00 01
[   96.547619] [drm:intel_dp_detect] Display Port TPS3 support: source yes, 
sink yes
[   96.547622] [drm:intel_dp_print_rates] source rates: 162000, 27, 54
[   96.547624] [drm:intel_dp_print_rates] sink rates: 162000, 27, 54
[   96.547625] [drm:intel_dp_print_rates] common rates: 162000, 27, 54
[   96.549257] 

Re: [Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug

2017-02-16 Thread Palmer Dabbelt
On Tue, Feb 14, 2017 at 11:00 AM, Ville Syrjälä
 wrote:
> On Tue, Feb 14, 2017 at 10:48:10AM -0800, Palmer Dabbelt wrote:
>> On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrj...@linux.intel.com 
>> wrote:
>> > On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote:
>> >> DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro
>> >> attached to an ASUS PB287Q).  I believe the problem is that long pulses
>> >> are no longer triggering intel_dp_check_link_status.
>> >
>> > That shouldn't itsefl cause problems with hotplugs. It could cause
>> > problems if you hotplug displays without a proper randr client running
>> > in which case the link is left running when you unplug the displays and
>> > then gets retrained when you plug a display back in.
>>
>> Maybe it's a problem with my setup, as I don't think I have any randr client
>> running: I just run xrandr via my xinitrc and via some scripts linked from 
>> udev
>> for DRM hotplug events for when I move the laptop around.
>
> That should more or less work. Well, depends on what you do in your
> udev scripts. But that's pretty much what your typical xrandr clients
> do, except the udev event gets first converted into a randr event by the
> X server.
>
>> Is it required that
>> I have more stuff running in order to make DPMS events work?
>
> Not sure what you mean by DPMS events. "xset dpms" just turns things
> on/off, there are no events involved really.

I guess my "dpms event" I meant "the monitor going on and off".

>> IIRC my setup has
>> looked like this for years now, but if it's broken because it's wacky then I
>> can change it.
>>
>> Regardless, I think something is still broken here.  I don't need to actaully
>> unplug anything for this to break, if I just run "xset dpms force off" to 
>> turn
>> the screen off and then wake it back up my eDP laptop display comes back fine
>> but my DP monitor doesn't.
>
> That is definitely a bug somewhere. Can you boot your machine with
> drm.debug=0xe passed to the kernel, then reproduce this dpms problem,
> and then post the full dmesg. Maybe the log will show something
> interesting.

Attached.  There's two copies: one from after I boot and start X, and
the second from after I do a DPMS cycle:

  $ xset dpms force off
  $ sleep 10s # wait for the monitor to go to sleep
  # press ctrl to wake the monitor back up

One item of interest: when I ran this on my work monitor (a newer Dell
DisplayPort monitor) I didn't have any DPMS problems, but when I ran
it on my ASUS PB287Q the monitor doesn't come back from sleep.

>> I'd expect eDP and DP to behave the same here.
>> IIRC the link doesn't come back up even if I twiddle some xrandr stuff, but I
>> might getting this confused with the previous similar bug.  If you want I can
>> boot back into the broken kernel and run some experiments, but it'd be great 
>> if
>> you could suggest some for me.
>>
>> > That doesn't explain why intel_dp_check_link_status() wouldn't get
>> > called though. It should be called via intel_dp_detect() ->
>> > intel_dp_long_pulse().
>>
>> Sorry, I don't actually know anything about DRM so I'm not sure what's going
>> on.  I just generated this patch by looking at the bug from last time my DP
>> monitor stopped working, looking at the last few things that touched that
>> function, and then adding back in the thing that looks like it would make 
>> link
>> detection work again :).
>
> Well, it should already work. Somehting is hinky.
>
>>
>> The last time I did this I got it wrong as well -- looking at
>>  I see that I suggested
>>
>>   diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>>   index d714a4b5711e..274bd293d9e9 100644
>>   --- a/drivers/gpu/drm/i915/intel_dp.c
>>   +++ b/drivers/gpu/drm/i915/intel_dp.c
>>   @@ -4625,7 +4625,9 @@ static const struct drm_encoder_funcs 
>> intel_dp_enc_funcs = {
>>void
>>intel_dp_hot_plug(struct intel_encoder *intel_encoder)
>>{
>>   -   return;
>>   +   struct intel_dp *intel_dp = enc_to_intel_dp(_encoder->base);
>>   +
>>   +   intel_dp_check_link_status(intel_dp);
>>}
>>
>>  enum irqreturn
>>
>> but the correct solution (d14e7b6d1 "drm/i915: Check DP link status on long 
>> hpd
>> too") was very different
>>
>>   diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>>   index 3781cd3..94686cb 100644
>>   --- a/drivers/gpu/drm/i915/intel_dp.c
>>   +++ b/drivers/gpu/drm/i915/intel_dp.c
>>   @@ -4961,9 +4961,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
>> *intel_dig_port, bool long_hpd)
>>
>>   intel_dp_probe_oui(intel_dp);
>>
>>   -   if (!intel_dp_probe_mst(intel_dp))
>>   +   if (!intel_dp_probe_mst(intel_dp)) {
>>   +   
>> drm_modeset_lock(>mode_config.connection_mutex, NULL);
>>   +   intel_dp_check_link_status(intel_dp);

Re: [Intel-gfx] [PATCH 8/9] drm/i915/bxt: Enable BXT DSI dual link

2017-02-16 Thread Jani Nikula
On Wed, 15 Feb 2017, Bob Paauwe  wrote:
> On Wed, 8 Feb 2017 16:20:57 +0530
> Vidya Srinivas  wrote:
>
>> From: Uma Shankar 
>> 
>> Enable support for BXT DSI dual link mode.
>> 
>> Signed-off-by: Uma Shankar 
>> Signed-off-by: Vidya Srinivas 
>
> Reviewed-by: Bob Paauwe 

This doesn't apply because I've pushed

commit 6043801f937ada9c9ed9dfa3c6ce542a79643401
Author: Deepak M 
Date:   Tue Feb 14 18:46:16 2017 +0530

drm/i915: Set the Z inversion overlap field

Please update the patch, and in general, please send a new series of
patches that do *not* depend on the drm_panel changes. We can get all of
those merged first. We should try to make progress.

BR,
Jani.


>
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h  |  5 +
>>  drivers/gpu/drm/i915/intel_dsi.c | 27 ++-
>>  2 files changed, 23 insertions(+), 9 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 07b1a2d..3b2925c 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -8425,6 +8425,7 @@ enum {
>>  #define  LANE_CONFIGURATION_4LANE   (0 << 0)
>>  #define  LANE_CONFIGURATION_DUAL_LINK_A (1 << 0)
>>  #define  LANE_CONFIGURATION_DUAL_LINK_B (2 << 0)
>> +#define  LANE_CONFIGURATION_DUAL_LINK_ENABLE(1 << 0)
>>  
>>  #define _MIPIA_TEARING_CTRL (VLV_DISPLAY_BASE + 0x61194)
>>  #define _MIPIC_TEARING_CTRL (VLV_DISPLAY_BASE + 0x61704)
>> @@ -8758,6 +8759,10 @@ enum {
>>  #define  READ_REQUEST_PRIORITY_HIGH (3 << 3)
>>  #define  RGB_FLIP_TO_BGR(1 << 2)
>>  
>> +/* BXT has dual link Z inversion overlap field */
>> +#define  BXT_PIXEL_OVERLAP_CNT_MASK (0xf << 10)
>> +#define  BXT_PIXEL_OVERLAP_CNT_SHIFT10
>> +
>>  #define  BXT_PIPE_SELECT_SHIFT  7
>>  #define  BXT_PIPE_SELECT_MASK   (7 << 7)
>>  #define  BXT_PIPE_SELECT(pipe)  ((pipe) << 7)
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 12aeee1..60ca0b9 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -440,15 +440,24 @@ static void intel_dsi_port_enable(struct intel_encoder 
>> *encoder)
>>  struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
>>  struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>>  enum port port;
>> +u32 temp;
>>  
>>  if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
>> -u32 temp;
>> -
>> -temp = I915_READ(VLV_CHICKEN_3);
>> -temp &= ~PIXEL_OVERLAP_CNT_MASK |
>> +if (IS_BROXTON(dev_priv)) {
>> +for_each_dsi_port(port, intel_dsi->ports) {
>> +temp = I915_READ(MIPI_CTRL(port));
>> +temp &= ~BXT_PIXEL_OVERLAP_CNT_MASK |
>>  intel_dsi->pixel_overlap <<
>> -PIXEL_OVERLAP_CNT_SHIFT;
>> -I915_WRITE(VLV_CHICKEN_3, temp);
>> +BXT_PIXEL_OVERLAP_CNT_SHIFT;
>> +I915_WRITE(MIPI_CTRL(port), temp);
>> +}
>> +} else {
>> +temp = I915_READ(VLV_CHICKEN_3);
>> +temp &= ~PIXEL_OVERLAP_CNT_MASK |
>> +intel_dsi->pixel_overlap <<
>> +PIXEL_OVERLAP_CNT_SHIFT;
>> +I915_WRITE(VLV_CHICKEN_3, temp);
>> +}
>>  }
>>  
>>  for_each_dsi_port(port, intel_dsi->ports) {
>> @@ -464,12 +473,12 @@ static void intel_dsi_port_enable(struct intel_encoder 
>> *encoder)
>>  if (intel_dsi->ports == (BIT(PORT_A) | BIT(PORT_C))) {
>>  temp |= (intel_dsi->dual_link - 1)
>>  << DUAL_LINK_MODE_SHIFT;
>> -if (IS_BROXTON(dev_priv))
>> -temp |= LANE_CONFIGURATION_DUAL_LINK_A;
>> -else
>> +if (IS_VALLEYVIEW(dev_priv))
>>  temp |= intel_crtc->pipe ?
>>  LANE_CONFIGURATION_DUAL_LINK_B :
>>  LANE_CONFIGURATION_DUAL_LINK_A;
>> +else if (IS_BROXTON(dev_priv))
>> +temp |= LANE_CONFIGURATION_DUAL_LINK_ENABLE;
>>  }
>>  /* assert ip_tg_enable signal */
>>  I915_WRITE(port_ctrl, temp | DPI_ENABLE);

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GLK MIPI DSI VIDEO MODE PATCHES (rev5)

2017-02-16 Thread Jani Nikula
On Tue, 14 Feb 2017, Patchwork  wrote:
> drivers/gpu/drm/i915/intel_dsi_pll.c: In function ‘intel_compute_dsi_pll’:
> drivers/gpu/drm/i915/intel_dsi_pll.c:513:45: error: ‘dsi_ratio_max’ may be 
> used uninitialized in this function [-Werror=maybe-uninitialized]
>   if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
>  ^
> drivers/gpu/drm/i915/intel_dsi_pll.c:492:31: note: ‘dsi_ratio_max’ was 
> declared here
>   u8 dsi_ratio, dsi_ratio_min, dsi_ratio_max;
>^
>   LD  drivers/tty/serial/built-in.o
>   LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
> cc1: all warnings being treated as errors
> scripts/Makefile.build:294: recipe for target 
> 'drivers/gpu/drm/i915/intel_dsi_pll.o' failed
> make[4]: *** [drivers/gpu/drm/i915/intel_dsi_pll.o] Error 1
> make[4]: *** Waiting for unfinished jobs

The series didn't get tested because of this. Please update the series
and repost, and do remember to add the Reviewed-by tags to the patches
I've reviewed so far.

Thanks,
Jani.



-- 
Jani Nikula, 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 7/9] drm/i915/bxt: Disable device ready before shutdown command

2017-02-16 Thread Jani Nikula
On Wed, 15 Feb 2017, Bob Paauwe  wrote:
> On Wed, 8 Feb 2017 16:20:56 +0530
> Vidya Srinivas  wrote:
>
>> From: Uma Shankar 
>> 
>> Disable device ready before MIPI port shutdown command.
>> This helps to avoid mipi split screen issues.
>> 
>> Signed-off-by: Uma Shankar 
>> Signed-off-by: Vidya Srinivas 
>
> Reviewed-by: Bob Paauwe 

Pushed this one patch to dinq, thanks for the patch and review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/intel_dsi.c | 11 +++
>>  1 file changed, 11 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index 808158f..12aeee1 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -603,6 +603,8 @@ static void intel_dsi_pre_disable(struct intel_encoder 
>> *encoder,
>>struct intel_crtc_state *old_crtc_state,
>>struct drm_connector_state *old_conn_state)
>>  {
>> +struct drm_device *dev = encoder->base.dev;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>>  struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>>  enum port port;
>>  
>> @@ -610,6 +612,15 @@ static void intel_dsi_pre_disable(struct intel_encoder 
>> *encoder,
>>  
>>  intel_panel_disable_backlight(intel_dsi->attached_connector);
>>  
>> +/*
>> + * Disable Device ready before the port shutdown in order
>> + * to avoid split screen
>> + */
>> +if (IS_BROXTON(dev_priv)) {
>> +for_each_dsi_port(port, intel_dsi->ports)
>> +I915_WRITE(MIPI_DEVICE_READY(port), 0);
>> +}
>> +
>>  if (is_vid_mode(intel_dsi)) {
>>  /* Send Shutdown command to the panel in LP mode */
>>  for_each_dsi_port(port, intel_dsi->ports)

-- 
Jani Nikula, 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 5/9] drm/i915/bxt: Fix BXT DSI ULPS sequence

2017-02-16 Thread Jani Nikula
On Wed, 15 Feb 2017, Bob Paauwe  wrote:
> On Wed, 8 Feb 2017 16:20:54 +0530
> Vidya Srinivas  wrote:
>
>> From: Uma Shankar 
>> 
>> Fix the Sequence to program BXT DSI Latch and ULPS.
>> 
>> Signed-off-by: Uma Shankar 
>> Signed-off-by: Vidya Srinivas 
>
> Reviewed-by: Bob Paauwe 

Pushed this one patch to dinq, thanks for the patch and review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/intel_dsi.c | 23 +--
>>  1 file changed, 5 insertions(+), 18 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index c297ea9..538755b 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -366,32 +366,19 @@ static void bxt_dsi_device_ready(struct intel_encoder 
>> *encoder)
>>  
>>  DRM_DEBUG_KMS("\n");
>>  
>> -/* Exit Low power state in 4 steps*/
>> +/* Enable MIPI PHY transparent latch */
>>  for_each_dsi_port(port, intel_dsi->ports) {
>> -
>> -/* 1. Enable MIPI PHY transparent latch */
>>  val = I915_READ(BXT_MIPI_PORT_CTRL(port));
>>  I915_WRITE(BXT_MIPI_PORT_CTRL(port), val | LP_OUTPUT_HOLD);
>>  usleep_range(2000, 2500);
>> +}
>>  
>> -/* 2. Enter ULPS */
>> -val = I915_READ(MIPI_DEVICE_READY(port));
>> -val &= ~ULPS_STATE_MASK;
>> -val |= (ULPS_STATE_ENTER | DEVICE_READY);
>> -I915_WRITE(MIPI_DEVICE_READY(port), val);
>> -/* at least 2us - relaxed for hrtimer subsystem optimization */
>> -usleep_range(10, 50);
>> -
>> -/* 3. Exit ULPS */
>> +/* Clear ULPS and set device ready */
>> +for_each_dsi_port(port, intel_dsi->ports) {
>>  val = I915_READ(MIPI_DEVICE_READY(port));
>>  val &= ~ULPS_STATE_MASK;
>> -val |= (ULPS_STATE_EXIT | DEVICE_READY);
>>  I915_WRITE(MIPI_DEVICE_READY(port), val);
>> -usleep_range(1000, 1500);
>> -
>> -/* Clear ULPS and set device ready */
>> -val = I915_READ(MIPI_DEVICE_READY(port));
>> -val &= ~ULPS_STATE_MASK;
>> +usleep_range(2000, 2500);
>>  val |= DEVICE_READY;
>>  I915_WRITE(MIPI_DEVICE_READY(port), val);
>>  }

-- 
Jani Nikula, 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] [GLK MIPI DSI V5 4/8] drm/i915: Set the Z inversion overlap field

2017-02-16 Thread Jani Nikula
On Tue, 14 Feb 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> Dual link Z-inversion overlap field is present
> in MIPI_CTRL register unlike the older platforms,
> hence setting the same in this patch.
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 

Pushed this one patch to dinq. This one is really bxt specific, and
should have been first in the series.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index a72a10f..ef643c1 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -561,12 +561,21 @@ static void intel_dsi_port_enable(struct intel_encoder 
> *encoder)
>  
>   if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
>   u32 temp;
> -
> - temp = I915_READ(VLV_CHICKEN_3);
> - temp &= ~PIXEL_OVERLAP_CNT_MASK |
> + if (IS_GEN9_LP(dev_priv)) {
> + for_each_dsi_port(port, intel_dsi->ports) {
> + temp = I915_READ(MIPI_CTRL(port));
> + temp &= ~BXT_PIXEL_OVERLAP_CNT_MASK |
> + intel_dsi->pixel_overlap <<
> + BXT_PIXEL_OVERLAP_CNT_SHIFT;
> + I915_WRITE(MIPI_CTRL(port), temp);
> + }
> + } else {
> + temp = I915_READ(VLV_CHICKEN_3);
> + temp &= ~PIXEL_OVERLAP_CNT_MASK |
>   intel_dsi->pixel_overlap <<
>   PIXEL_OVERLAP_CNT_SHIFT;
> - I915_WRITE(VLV_CHICKEN_3, temp);
> + I915_WRITE(VLV_CHICKEN_3, temp);
> + }
>   }
>  
>   for_each_dsi_port(port, intel_dsi->ports) {

-- 
Jani Nikula, 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] [GLK MIPI DSI V5 6/8] drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT

2017-02-16 Thread Jani Nikula
On Tue, 14 Feb 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> Register MIPI_CLOCK_CTRL is applicable only
> for BXT platform. Future platform have other
> registers to program the escape clock dividers.
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_dsi_pll.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index e6383cb..aadf7de 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -493,8 +493,10 @@ static void bxt_enable_dsi_pll(struct intel_encoder 
> *encoder,
>   POSTING_READ(BXT_DSI_PLL_CTL);
>  
>   /* Program TX, RX, Dphy clocks */
> - for_each_dsi_port(port, intel_dsi->ports)
> - bxt_dsi_program_clocks(encoder->base.dev, port, config);
> + if (IS_BROXTON(dev_priv)) {
> + for_each_dsi_port(port, intel_dsi->ports)
> + bxt_dsi_program_clocks(encoder->base.dev, port, config);
> + }
>  
>   /* Enable DSI PLL */
>   val = I915_READ(BXT_DSI_PLL_ENABLE);
> @@ -558,19 +560,22 @@ void intel_disable_dsi_pll(struct intel_encoder 
> *encoder)
>   bxt_disable_dsi_pll(encoder);
>  }
>  
> -static void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port 
> port)
> +static void gen9lp_dsi_reset_clocks(struct intel_encoder *encoder,
> + enum port port)
>  {
>   u32 tmp;
>   struct drm_device *dev = encoder->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
>   /* Clear old configurations */
> - tmp = I915_READ(BXT_MIPI_CLOCK_CTL);
> - tmp &= ~(BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port));
> - tmp &= ~(BXT_MIPI_RX_ESCLK_UPPER_FIXDIV_MASK(port));
> - tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
> - tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
> - I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
> + if (IS_BROXTON(dev_priv)) {
> + tmp = I915_READ(BXT_MIPI_CLOCK_CTL);
> + tmp &= ~(BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port));
> + tmp &= ~(BXT_MIPI_RX_ESCLK_UPPER_FIXDIV_MASK(port));
> + tmp &= ~(BXT_MIPI_8X_BY3_DIVIDER_MASK(port));
> + tmp &= ~(BXT_MIPI_RX_ESCLK_LOWER_FIXDIV_MASK(port));
> + I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
> + }
>   I915_WRITE(MIPI_EOT_DISABLE(port), CLOCKSTOP);
>  }
>  
> @@ -579,7 +584,7 @@ void intel_dsi_reset_clocks(struct intel_encoder 
> *encoder, enum port port)
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>  
>   if (IS_GEN9_LP(dev_priv))
> - bxt_dsi_reset_clocks(encoder, port);
> + gen9lp_dsi_reset_clocks(encoder, port);
>   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   vlv_dsi_reset_clocks(encoder, 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


Re: [Intel-gfx] [PATCH 3/4] drm/i915/gen9: Fix clearing of the BIOS power well request register

2017-02-16 Thread Imre Deak
On Thu, Feb 16, 2017 at 11:43:06AM +0200, Ander Conselvan De Oliveira wrote:
> On Wed, 2017-02-15 at 13:59 +0200, Imre Deak wrote:
> > Atm, in the power well sync_hw hook we are clearing all BIOS request
> > bits, not just the one corresponding to the given power well. This could
> > turn off an unrelated power well inadvertently if it didn't have a
> > request bit set in the driver request register.
> > 
> > This didn't cause a problem so far, since we enabled all power wells
> > explicitly before clearing the BIOS request register. A follow-up
> > patchset will add power wells that won't get enabled this way, so fix up
> > the inconsistency.
> > 
> > Cc: Ander Conselvan de Oliveira 
> > Cc: David Weinehall 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index f9aff26..b7b0e0f 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -887,8 +887,13 @@ static bool skl_power_well_enabled(struct 
> > drm_i915_private *dev_priv,
> >  static void skl_power_well_sync_hw(struct drm_i915_private *dev_priv,
> > struct i915_power_well *power_well)
> >  {
> > +   uint32_t mask = SKL_POWER_WELL_REQ(power_well->id);
> > +   uint32_t bios_req = I915_READ(HSW_PWR_WELL_BIOS);
> > +
> > /* Clear any request made by BIOS as driver is taking over */
> > -   I915_WRITE(HSW_PWR_WELL_BIOS, 0);
> > +   if (bios_req & mask) {
> > +   I915_WRITE(HSW_PWR_WELL_BIOS, bios_req & ~mask);
> > +   }
> >  }
> >  
> >  static void skl_power_well_enable(struct drm_i915_private *dev_priv,
> 
> With this change we still end up disabling every power well from the BIOS
> register because of intel_power_domains_sync_hw() iterating over all the power
> wells. 

Yes, that's what is expected. This patch just changes how this clearing
is done, the next one makes sure we preserve the state for any power
well without a reference.

> Maybe that's worth mentioning in the commit message? Dunno.

Ok, will add something.

> Anyway,
> 
> Reviewed-by: Ander Conselvan de Oliveira 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [GLK MIPI DSI V5 5/8] drm/i915/glk: Add DSI PLL divider range for glk

2017-02-16 Thread Jani Nikula
On Tue, 14 Feb 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> PLL divider range for GLK is different than that of
> BXT, hence adding the GLK range check in this patch.
>
> v2: Code restructure using min and max ratio variables (Ander)
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  4 
>  drivers/gpu/drm/i915/intel_dsi_pll.c | 24 +---
>  2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c09f665..2cd7ff7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8348,10 +8348,12 @@ enum {
>  #define  BXT_DSI_PLL_PVD_RATIO_SHIFT 16
>  #define  BXT_DSI_PLL_PVD_RATIO_MASK  (3 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
>  #define  BXT_DSI_PLL_PVD_RATIO_1 (1 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
> +#define  BXT_DSIC_16X_BY1(0 << 10)
>  #define  BXT_DSIC_16X_BY2(1 << 10)
>  #define  BXT_DSIC_16X_BY3(2 << 10)
>  #define  BXT_DSIC_16X_BY4(3 << 10)
>  #define  BXT_DSIC_16X_MASK   (3 << 10)
> +#define  BXT_DSIA_16X_BY1(0 << 8)
>  #define  BXT_DSIA_16X_BY2(1 << 8)
>  #define  BXT_DSIA_16X_BY3(2 << 8)
>  #define  BXT_DSIA_16X_BY4(3 << 8)
> @@ -8361,6 +8363,8 @@ enum {
>  
>  #define BXT_DSI_PLL_RATIO_MAX0x7D
>  #define BXT_DSI_PLL_RATIO_MIN0x22
> +#define GLK_DSI_PLL_RATIO_MAX0x6F
> +#define GLK_DSI_PLL_RATIO_MIN0x22
>  #define BXT_DSI_PLL_RATIO_MASK   0xFF
>  #define BXT_REF_CLOCK_KHZ19200
>  
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index 61440e5..e6383cb 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -430,11 +430,12 @@ static void bxt_dsi_program_clocks(struct drm_device 
> *dev, enum port port,
>   I915_WRITE(BXT_MIPI_CLOCK_CTL, tmp);
>  }
>  
> -static int bxt_compute_dsi_pll(struct intel_encoder *encoder,
> +static int gen9lp_compute_dsi_pll(struct intel_encoder *encoder,
>  struct intel_crtc_state *config)
>  {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> - u8 dsi_ratio;
> + u8 dsi_ratio, dsi_ratio_min, dsi_ratio_max;
>   u32 dsi_clk;
>  
>   dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
> @@ -446,11 +447,20 @@ static int bxt_compute_dsi_pll(struct intel_encoder 
> *encoder,
>* round 'up' the result
>*/
>   dsi_ratio = DIV_ROUND_UP(dsi_clk * 2, BXT_REF_CLOCK_KHZ);
> - if (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
> - dsi_ratio > BXT_DSI_PLL_RATIO_MAX) {
> +
> + if (IS_BROXTON(dev_priv)) {
> + dsi_ratio_min = BXT_DSI_PLL_RATIO_MIN;
> + dsi_ratio_max = BXT_DSI_PLL_RATIO_MAX;
> + } else if (IS_GEMINILAKE(dev_priv)) {

This else if causes

 drivers/gpu/drm/i915/intel_dsi_pll.c: In function ‘intel_compute_dsi_pll’:
 drivers/gpu/drm/i915/intel_dsi_pll.c:513:45: error: ‘dsi_ratio_max’ may be
 used uninitialized in this function [-Werror=maybe-uninitialized]
   if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
  ^
 drivers/gpu/drm/i915/intel_dsi_pll.c:492:31: note: ‘dsi_ratio_max’ was
 declared here
   u8 dsi_ratio, dsi_ratio_min, dsi_ratio_max;
^

And things like this in our driver generally beg the question, what
*other* platforms than the mentioned ones could run this code.

Just change that to an else.

BR,
Jani.


> + dsi_ratio_min = GLK_DSI_PLL_RATIO_MIN;
> + dsi_ratio_max = GLK_DSI_PLL_RATIO_MAX;
> + }
> +
> + if (dsi_ratio < dsi_ratio_min || dsi_ratio > dsi_ratio_max) {
>   DRM_ERROR("Cant get a suitable ratio from DSI PLL ratios\n");
>   return -ECHRNG;
> - }
> + } else
> + DRM_DEBUG_KMS("DSI PLL calculation is Done!!\n");
>  
>   /*
>* Program DSI ratio and Select MIPIC and MIPIA PLL output as 8x
> @@ -462,7 +472,7 @@ static int bxt_compute_dsi_pll(struct intel_encoder 
> *encoder,
>   /* As per recommendation from hardware team,
>* Prog PVD ratio =1 if dsi ratio <= 50
>*/
> - if (dsi_ratio <= 50)
> + if (IS_BROXTON(dev_priv) && dsi_ratio <= 50)
>   config->dsi_pll.ctrl |= BXT_DSI_PLL_PVD_RATIO_1;
>  
>   return 0;
> @@ -522,7 +532,7 @@ int intel_compute_dsi_pll(struct intel_encoder *encoder,
>   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   return vlv_compute_dsi_pll(encoder, config);
>   else if (IS_GEN9_LP(dev_priv))
> - return 

Re: [Intel-gfx] [GLK MIPI DSI V5 3/8] drm/i915/glk: Add MIPIIO Enable/disable sequence

2017-02-16 Thread Jani Nikula
On Tue, 14 Feb 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
> v3: Jani's Review comment for aligning code to platforms and added
> wrapper functions.
> v4: Corrected enable/disable seuqence as per BSPEC
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 206 
> ---
>  1 file changed, 195 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 03d0999..a72a10f 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct 
> intel_encoder *encoder,
>   return true;
>  }
>  
> +static void glk_dsi_device_ready(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + enum port port;
> + u32 tmp, val;
> +
> + /* Set the MIPI mode
> +  * If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
> +  * Power ON MIPI IO first and then write into IO reset and LP wake bits
> +  */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(MIPI_CTRL(port));
> + I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
> + }
> +
> + /* Put the IO into reset */
> + tmp = I915_READ(MIPI_CTRL(PORT_A));
> + tmp &= ~GLK_MIPIIO_RESET_RELEASED;
> + I915_WRITE(MIPI_CTRL(PORT_A), tmp);
> +
> + /* Program LP Wake */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(MIPI_CTRL(port));
> + tmp |= GLK_LP_WAKE;
> + I915_WRITE(MIPI_CTRL(port), tmp);
> + }
> +
> + /* Wait for Pwr ACK */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
> + GLK_MIPIIO_PORT_POWERED, 20))
> + DRM_ERROR("Power ACK not received\n");
> + }
> +
> + /* Wait for MIPI PHY status bit to set */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
> + GLK_MIPIIO_PORT_POWERED, 20))
> + DRM_ERROR("PHY is not ON\n");
> + }

You have the same wait twice here, with different comments and error
messages.

> +
> + /* Get IO out of reset */
> + tmp = I915_READ(MIPI_CTRL(PORT_A));
> + I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED);
> +
> + /* Get IO out of Low power state*/
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) {
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= DEVICE_READY;
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> + usleep_range(10, 15);
> + }
> +
> + /* Enter ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_ENTER | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + /* Wait for ULPS Not active */
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> + GLK_ULPS_NOT_ACTIVE, 20))
> +
> + /* Exit ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_EXIT | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + /* Enter Normal Mode */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + tmp = I915_READ(MIPI_CTRL(port));
> + tmp &= ~GLK_LP_WAKE;
> + I915_WRITE(MIPI_CTRL(port), tmp);
> + }
> +
> + /* Wait for Stop state */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_DATA_LANE_STOP_STATE,
> + GLK_DATA_LANE_STOP_STATE, 20))
> + DRM_ERROR("Date lane not in STOP state\n");
> + }
> +
> + /* Wait for AFE LATCH */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: handle override/firmware edid at the lowest level

2017-02-16 Thread Patchwork
== Series Details ==

Series: drm: handle override/firmware edid at the lowest level
URL   : https://patchwork.freedesktop.org/series/19764/
State : failure

== Summary ==

Series 19764v1 drm: handle override/firmware edid at the lowest level
https://patchwork.freedesktop.org/api/1.0/series/19764/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-snb-2520m)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-snb-2600)
Subgroup prune-stale-modes:
pass   -> FAIL   (fi-byt-j1900)
pass   -> FAIL   (fi-snb-2520m)
pass   -> FAIL   (fi-ivb-3770)
pass   -> FAIL   (fi-ivb-3520m)
pass   -> FAIL   (fi-snb-2600)

fi-bdw-5557u total:252  pass:241  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:252  pass:213  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:252  pass:233  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:83   pass:70   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:252  pass:223  dwarn:0   dfail:0   fail:2   skip:27 
fi-byt-n2820 total:252  pass:221  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:252  pass:236  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:252  pass:202  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:252  pass:232  dwarn:0   dfail:0   fail:2   skip:18 
fi-ivb-3770  total:252  pass:232  dwarn:0   dfail:0   fail:2   skip:18 
fi-kbl-7500u total:252  pass:234  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:252  pass:235  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:252  pass:230  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:252  pass:242  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:252  pass:222  dwarn:0   dfail:0   fail:2   skip:28 
fi-snb-2600  total:252  pass:221  dwarn:0   dfail:0   fail:2   skip:29 

89a932d98b6e1733011019c9872583a9c7c8fda3 drm-tip: 2017y-02m-16d-10h-06m-42s UTC 
integration manifest
ee36efc drm: handle override edid and firmware adid at drm_do_get_edid()
21cd354 drm: reset ELD if NULL edid is passed to drm_edid_to_eld
a0f096f drm: move edid property update and add modes out of edid firmware loader

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3852/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Call the sync_hw hook for power wells without a domain

2017-02-16 Thread Imre Deak
On Thu, Feb 16, 2017 at 11:31:01AM +0200, Ander Conselvan De Oliveira wrote:
> On Wed, 2017-02-15 at 13:59 +0200, Imre Deak wrote:
> > So far the sync_hw hook wasn't called for power wells not belonging to
> > any power domain, that is the GEN9 PW1 and MISC_IO power wells. This
> > wasn't a problem so far since the goal of the sync_hw hook - to clear
> > the corresponding BIOS request bit - was guaranteed by clearing the
> > whole BIOS request register elsewhere. This will change with the next
> > patch, so fix up the inconsistency.
> > 
> > Cc: Ander Conselvan de Oliveira 
> > Cc: David Weinehall 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 34 
> > +
> >  1 file changed, 22 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 0f64bc1..f9aff26 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -49,17 +49,24 @@
> >   * present for a given platform.
> >   */
> >  
> > -#define for_each_power_well(i, power_well, domain_mask, power_domains) 
> > \
> > -   for (i = 0; \
> > -i < (power_domains)->power_well_count &&   \
> > +#define for_each_power_well(i, power_well) \
> > +   for ((i) = 0;   \
> > +(i) < (power_domains)->power_well_count && \
> 
> This now requires that power_domains is in scope to work properly. Would it 
> make
> sense to still pass that as argument to the macro or, alternatively, pass
> dev_priv?

Yes, that was a copy/paste fail. Yep, dev_priv simplifies things, will
change to that.

> Could probably nuke the i parameter too, since no caller uses it?

Ok. I also moved these to i915_dev.h. I'll resend the patchset after a
trybot round.

> 
> But either way,
> 
> Reviewed-by: Ander Conselvan de Oliveira 

Thanks,
Imre

> 
> >  ((power_well) = &(power_domains)->power_wells[i]); \
> > -i++)   \
> > +(i)++)
> > +
> > +#define for_each_power_well_rev(i, power_well) 
> >  \
> > +   for ((i) = (power_domains)->power_well_count - 1;  \
> > +(i) >= 0 && ((power_well) = &(power_domains)->power_wells[i]);\
> > +(i)--)
> > +
> > +#define for_each_power_domain_well(i, power_well, domain_mask, 
> > power_domains) \
> > +   for_each_power_well(i, power_well)  \
> > for_each_if ((power_well)->domains & (domain_mask))
> >  
> > -#define for_each_power_well_rev(i, power_well, domain_mask, power_domains) 
> > \
> > -   for (i = (power_domains)->power_well_count - 1;  \
> > -i >= 0 && ((power_well) = &(power_domains)->power_wells[i]);\
> > -i--)\
> > +#define for_each_power_domain_well_rev(i, power_well, domain_mask, \
> > +  power_domains)   \
> > +   for_each_power_well_rev(i, power_well)  \
> > for_each_if ((power_well)->domains & (domain_mask))
> >  
> >  bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
> > @@ -210,7 +217,8 @@ bool __intel_display_power_is_enabled(struct 
> > drm_i915_private *dev_priv,
> >  
> > is_enabled = true;
> >  
> > -   for_each_power_well_rev(i, power_well, BIT_ULL(domain), power_domains) {
> > +   for_each_power_domain_well_rev(i, power_well, BIT_ULL(domain),
> > +  power_domains) {
> > if (power_well->always_on)
> > continue;
> >  
> > @@ -1665,7 +1673,8 @@ __intel_display_power_get_domain(struct 
> > drm_i915_private *dev_priv,
> > struct i915_power_well *power_well;
> > int i;
> >  
> > -   for_each_power_well(i, power_well, BIT_ULL(domain), power_domains)
> > +   for_each_power_domain_well(i, power_well, BIT_ULL(domain),
> > +  power_domains)
> > intel_power_well_get(dev_priv, power_well);
> >  
> > power_domains->domain_use_count[domain]++;
> > @@ -1760,7 +1769,8 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> >  intel_display_power_domain_str(domain));
> > power_domains->domain_use_count[domain]--;
> >  
> > -   for_each_power_well_rev(i, power_well, BIT_ULL(domain), power_domains)
> > +   for_each_power_domain_well_rev(i, power_well, BIT_ULL(domain),
> > +  power_domains)
> > intel_power_well_put(dev_priv, power_well);
> >  
> > 

Re: [Intel-gfx] [GLK MIPI DSI V5 2/8] drm/i915/glk: Program new MIPI DSI PHY registers for GLK

2017-02-16 Thread Jani Nikula
On Tue, 14 Feb 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> Program the clk lane and tlpx time count registers
> to configure DSI PHY.
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
> v3: Program clk lane timing reg same as dphy param reg.
> v4: Removed "line over 80 character" warning
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 8 
>  drivers/gpu/drm/i915/intel_dsi.c | 8 
>  2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 141a5c1..c09f665 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8636,6 +8636,14 @@ enum {
>  #define  LP_BYTECLK_SHIFT0
>  #define  LP_BYTECLK_MASK (0x << 0)
>  
> +#define _MIPIA_TLPX_TIME_COUNT   (dev_priv->mipi_mmio_base + 
> 0xb0a4)
> +#define _MIPIC_TLPX_TIME_COUNT   (dev_priv->mipi_mmio_base + 
> 0xb8a4)
> +#define MIPI_TLPX_TIME_COUNT(port)_MMIO_MIPI(port, 
> _MIPIA_TLPX_TIME_COUNT, _MIPIC_TLPX_TIME_COUNT)
> +
> +#define _MIPIA_CLK_LANE_TIMING   (dev_priv->mipi_mmio_base + 
> 0xb098)
> +#define _MIPIC_CLK_LANE_TIMING   (dev_priv->mipi_mmio_base + 
> 0xb898)
> +#define MIPI_CLK_LANE_TIMING(port)_MMIO_MIPI(port, 
> _MIPIA_CLK_LANE_TIMING, _MIPIC_CLK_LANE_TIMING)
> +
>  /* bits 31:0 */
>  #define _MIPIA_LP_GEN_DATA   (dev_priv->mipi_mmio_base + 0xb064)
>  #define _MIPIC_LP_GEN_DATA   (dev_priv->mipi_mmio_base + 0xb864)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index c98234e..03d0999 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1303,6 +1303,14 @@ static void intel_dsi_prepare(struct intel_encoder 
> *intel_encoder,
>*/
>   I915_WRITE(MIPI_LP_BYTECLK(port), intel_dsi->lp_byte_clk);
>  
> + if (IS_GEMINILAKE(dev_priv)) {
> + I915_WRITE(MIPI_TLPX_TIME_COUNT(port),
> + intel_dsi->lp_byte_clk);
> + /* Shadow of DPHY reg */
> + I915_WRITE(MIPI_CLK_LANE_TIMING(port),
> + intel_dsi->dphy_reg);
> + }
> +
>   /* the bw essential for transmitting 16 long packets containing
>* 252 bytes meant for dcs write memory command is programmed in
>* this register in terms of byte clocks. based on dsi transfer

-- 
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] [PATCH v4 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v2.

2017-02-16 Thread Maarten Lankhorst
There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.

Changes since v1:
- Use old/new_*_state for variable names as much as possible. (pinchartl)
- Expand commit message.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 431 +++-
 1 file changed, 222 insertions(+), 209 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9203f3e933f7..7d432d9a18cf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -63,14 +63,15 @@
  */
 static void
 drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
+   struct drm_plane_state *old_plane_state,
struct drm_plane_state *plane_state,
struct drm_plane *plane)
 {
struct drm_crtc_state *crtc_state;
 
-   if (plane->state->crtc) {
+   if (old_plane_state->crtc) {
crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
plane->state->crtc);
+   
old_plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -92,7 +93,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
 static int handle_conflicting_encoders(struct drm_atomic_state *state,
   bool disable_conflicting_encoders)
 {
-   struct drm_connector_state *conn_state;
+   struct drm_connector_state *new_conn_state;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct drm_encoder *encoder;
@@ -104,15 +105,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 * part of the state. If the same encoder is assigned to multiple
 * connectors bail out.
 */
-   for_each_connector_in_state(state, connector, conn_state, i) {
+   for_each_new_connector_in_state(state, connector, new_conn_state, i) {
const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
struct drm_encoder *new_encoder;
 
-   if (!conn_state->crtc)
+   if (!new_conn_state->crtc)
continue;
 
if (funcs->atomic_best_encoder)
-   new_encoder = funcs->atomic_best_encoder(connector, 
conn_state);
+   new_encoder = funcs->atomic_best_encoder(connector, 
new_conn_state);
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
@@ -166,20 +167,20 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
goto out;
}
 
-   conn_state = drm_atomic_get_connector_state(state, connector);
-   if (IS_ERR(conn_state)) {
-   ret = PTR_ERR(conn_state);
+   new_conn_state = drm_atomic_get_connector_state(state, 
connector);
+   if (IS_ERR(new_conn_state)) {
+   ret = PTR_ERR(new_conn_state);
goto out;
}
 
DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
disabling [CONNECTOR:%d:%s]\n",
 encoder->base.id, encoder->name,
-conn_state->crtc->base.id, 
conn_state->crtc->name,
+new_conn_state->crtc->base.id, 
new_conn_state->crtc->name,
 connector->base.id, connector->name);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
conn_state->crtc);
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_conn_state->crtc);
 
-   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+   ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
if (ret)
goto out;
 
@@ -245,22 +246,22 @@ steal_encoder(struct drm_atomic_state *state,
 {
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
-   struct drm_connector_state *connector_state;
+   struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
struct drm_crtc *encoder_crtc;
 
-   if (connector_state->best_encoder != encoder)
+ 

[Intel-gfx] [PATCH v4 5/5] drm/blend: Use new atomic iterator macros.

2017-02-16 Thread Maarten Lankhorst
There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_blend.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index d7053bb67db6..a0d0d6843288 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -377,26 +377,26 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
int i, ret = 0;
 
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   crtc = plane_state->crtc;
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   crtc = new_plane_state->crtc;
if (!crtc)
continue;
-   if (plane->state->zpos != plane_state->zpos) {
-   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
-   crtc_state->zpos_changed = true;
+   if (old_plane_state->zpos != new_plane_state->zpos) {
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+   new_crtc_state->zpos_changed = true;
}
}
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (crtc_state->plane_mask != crtc->state->plane_mask ||
-   crtc_state->zpos_changed) {
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   if (old_crtc_state->plane_mask != new_crtc_state->plane_mask ||
+   new_crtc_state->zpos_changed) {
ret = drm_atomic_helper_crtc_normalize_zpos(crtc,
-   crtc_state);
+   
new_crtc_state);
if (ret)
return ret;
}
-- 
2.7.4

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


Re: [Intel-gfx] [GLK MIPI DSI V5 1/8] drm/i915/glk: Program dphy param reg for GLK

2017-02-16 Thread Jani Nikula
On Tue, 14 Feb 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> For GEMINILAKE, dphy param reg values are programmed in terms
> of HS byte clock count while for older platforms in terms of
> HS ddr clk count.
>
> v2: Added comments to clarify ddr clock count calculation
> v3: Use multiplier variable instead of IS_GEMINILAKE()
> check everywhere (Jani)
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 31 
> +++---
>  1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 8f683b8..d06e7f7 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -571,6 +571,7 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
> *intel_dsi, u16 panel_id)
>   u32 tclk_prepare_clkzero, ths_prepare_hszero;
>   u32 lp_to_hs_switch, hs_to_lp_switch;
>   u32 pclk, computed_ddr;
> + u32 mul;
>   u16 burst_mode_ratio;
>   enum port port;
>  
> @@ -674,11 +675,6 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
> *intel_dsi, u16 panel_id)
>   break;
>   }
>  
> - /*
> -  * ui(s) = 1/f [f in hz]
> -  * ui(ns) = 10^9 / (f*10^6) [f in Mhz] -> 10^3/f(Mhz)
> -  */
> -
>   /* in Kbps */
>   ui_num = NS_KHZ_RATIO;
>   ui_den = bitrate;
> @@ -692,21 +688,26 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
> *intel_dsi, u16 panel_id)
>*/
>   intel_dsi->lp_byte_clk = DIV_ROUND_UP(tlpx_ns * ui_den, 8 * ui_num);
>  
> - /* count values in UI = (ns value) * (bitrate / (2 * 10^6))
> + /* DDR clock period = 2 * UI
> +  * UI(sec) = 1/(bitrate * 10^3) (bitrate is in KHZ)
> +  * UI(nsec) = 10^6 / bitrate
> +  * DDR clock period (nsec) = 2 * UI = (2 * 10^6)/ bitrate
> +  * DDR clock count  = ns_value / DDR clock period
>*
> -  * Since txddrclkhs_i is 2xUI, all the count values programmed in
> -  * DPHY param register are divided by 2
> -  *
> -  * prepare count
> +  * For GEMINILAKE dphy_param_reg will be programmed in terms of
> +  * HS byte clock count for other platform in HS ddr clock count
>*/
> + mul = IS_GEMINILAKE(dev_priv) ? 8 : 2;
>   ths_prepare_ns = max(mipi_config->ths_prepare,
>mipi_config->tclk_prepare);
> - prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * 2);
> +
> + /* prepare count */
> + prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * mul);
>  
>   /* exit zero count */
>   exit_zero_cnt = DIV_ROUND_UP(
>   (ths_prepare_hszero - ths_prepare_ns) * ui_den,
> - ui_num * 2
> + ui_num * mul
>   );
>  
>   /*
> @@ -720,12 +721,12 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
> *intel_dsi, u16 panel_id)
>  
>   /* clk zero count */
>   clk_zero_cnt = DIV_ROUND_UP(
> - (tclk_prepare_clkzero - ths_prepare_ns)
> - * ui_den, 2 * ui_num);
> + (tclk_prepare_clkzero - ths_prepare_ns)
> + * ui_den, ui_num * mul);
>  
>   /* trail count */
>   tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
> - trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, 2 * ui_num);
> + trail_cnt = DIV_ROUND_UP(tclk_trail_ns * ui_den, ui_num * mul);
>  
>   if (prepare_cnt > PREPARE_CNT_MAX ||
>   exit_zero_cnt > EXIT_ZERO_CNT_MAX ||

-- 
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] [PATCH v4 3/5] drm/atomic: Add macros to access existing old/new state, v2.

2017-02-16 Thread Maarten Lankhorst
After atomic commit, these macros should be used in place of
get_existing_state. Also after commit get_xx_state should no longer
be used because it may not have the required locks.

The calls to drm_atomic_get_existing_$obj_state should no longer be
used, and converted over to these new calls.

Changes since v1:
- Expand commit message.
- Deprecate get_existing_*_state functions in the documentation.

Signed-off-by: Maarten Lankhorst 
---
 include/drm/drm_atomic.h | 108 +++
 1 file changed, 108 insertions(+)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index c6f355a970d2..0147a047878d 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -277,6 +277,9 @@ int drm_atomic_connector_set_property(struct drm_connector 
*connector,
  *
  * This function returns the crtc state for the given crtc, or NULL
  * if the crtc is not part of the global atomic state.
+ *
+ * This function is deprecated, @drm_atomic_get_old_crtc_state or
+ * @drm_atomic_get_new_crtc_state should be used instead.
  */
 static inline struct drm_crtc_state *
 drm_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
@@ -286,12 +289,44 @@ drm_atomic_get_existing_crtc_state(struct 
drm_atomic_state *state,
 }
 
 /**
+ * drm_atomic_get_old_crtc_state - get old crtc state, if it exists
+ * @state: global atomic state object
+ * @crtc: crtc to grab
+ *
+ * This function returns the old crtc state for the given crtc, or
+ * NULL if the crtc is not part of the global atomic state.
+ */
+static inline struct drm_crtc_state *
+drm_atomic_get_old_crtc_state(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+   return state->crtcs[drm_crtc_index(crtc)].old_state;
+}
+/**
+ * drm_atomic_get_new_crtc_state - get new crtc state, if it exists
+ * @state: global atomic state object
+ * @crtc: crtc to grab
+ *
+ * This function returns the new crtc state for the given crtc, or
+ * NULL if the crtc is not part of the global atomic state.
+ */
+static inline struct drm_crtc_state *
+drm_atomic_get_new_crtc_state(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+   return state->crtcs[drm_crtc_index(crtc)].new_state;
+}
+
+/**
  * drm_atomic_get_existing_plane_state - get plane state, if it exists
  * @state: global atomic state object
  * @plane: plane to grab
  *
  * This function returns the plane state for the given plane, or NULL
  * if the plane is not part of the global atomic state.
+ *
+ * This function is deprecated, @drm_atomic_get_old_plane_state or
+ * @drm_atomic_get_new_plane_state should be used instead.
  */
 static inline struct drm_plane_state *
 drm_atomic_get_existing_plane_state(struct drm_atomic_state *state,
@@ -301,12 +336,45 @@ drm_atomic_get_existing_plane_state(struct 
drm_atomic_state *state,
 }
 
 /**
+ * drm_atomic_get_old_plane_state - get plane state, if it exists
+ * @state: global atomic state object
+ * @plane: plane to grab
+ *
+ * This function returns the old plane state for the given plane, or
+ * NULL if the plane is not part of the global atomic state.
+ */
+static inline struct drm_plane_state *
+drm_atomic_get_old_plane_state(struct drm_atomic_state *state,
+  struct drm_plane *plane)
+{
+   return state->planes[drm_plane_index(plane)].old_state;
+}
+
+/**
+ * drm_atomic_get_new_plane_state - get plane state, if it exists
+ * @state: global atomic state object
+ * @plane: plane to grab
+ *
+ * This function returns the new plane state for the given plane, or
+ * NULL if the plane is not part of the global atomic state.
+ */
+static inline struct drm_plane_state *
+drm_atomic_get_new_plane_state(struct drm_atomic_state *state,
+  struct drm_plane *plane)
+{
+   return state->planes[drm_plane_index(plane)].new_state;
+}
+
+/**
  * drm_atomic_get_existing_connector_state - get connector state, if it exists
  * @state: global atomic state object
  * @connector: connector to grab
  *
  * This function returns the connector state for the given connector,
  * or NULL if the connector is not part of the global atomic state.
+ *
+ * This function is deprecated, @drm_atomic_get_old_connector_state or
+ * @drm_atomic_get_new_connector_state should be used instead.
  */
 static inline struct drm_connector_state *
 drm_atomic_get_existing_connector_state(struct drm_atomic_state *state,
@@ -321,6 +389,46 @@ drm_atomic_get_existing_connector_state(struct 
drm_atomic_state *state,
 }
 
 /**
+ * drm_atomic_get_old_connector_state - get connector state, if it exists
+ * @state: global atomic state object
+ * @connector: connector to grab
+ *
+ * This function returns the old connector state for the given connector,
+ * or NULL if the connector is not part of the global atomic state.
+ */
+static inline struct drm_connector_state *

[Intel-gfx] [PATCH v4 0/5] drm/atomic: Add accessor macros for all atomic state.

2017-02-16 Thread Maarten Lankhorst
Fifth iteration. Instead of trying to convert all drivers straight away,
implement all macros that are required to get state working.

Old situation:
Use obj->state, which can refer to old or new state.
Use drm_atomic_get_(existing_)obj_state, which can refer to new or old state.
Use for_each_obj_in_state, which refers to new or old state.

New situation:

During atomic check:
- Use drm_atomic_get_obj_state to add a object to the atomic state,
  or get the new state.
- Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state,
  without adding the object. This will return NULL if the object is
  not part of the state. For planes and connectors the relevant crtc_state
  is added, so this will work to get the crtc_state from obj_state->crtc
  too, this means not having to write some error handling. 

During atomic commit:
- Do not use drm_atomic_get_obj_state, obj->state or 
drm_atomic_get_(existing_)obj_state
  any more, replace with drm_atomic_get_old/new_obj_state calls as required.

During both:
- Use for_each_(new,old,oldnew)_obj_in_state to get the old or new state as 
needed.
  oldnew will be renamed to for_each_obj_in_state after all callers are 
converted
  to the new api.

When not doing atomic updates:
Look at obj->state for now. I have some patches to fix this but I was asked to
make it return a const state. This breaks a lot of users though so I skipped 
that
patch in this iteration.

This series will return the correct state regardless of swapping.

Maarten Lankhorst (5):
  drm/atomic: Fix atomic helpers to use the new iterator macros, v2.
  drm/atomic: Make drm_atomic_plane_disabling easier to understand.
  drm/atomic: Add macros to access existing old/new state, v2.
  drm/atomic: Convert get_existing_state callers to get_old/new_state,
v3.
  drm/blend: Use new atomic iterator macros.

 drivers/gpu/drm/drm_atomic.c|   6 +-
 drivers/gpu/drm/drm_atomic_helper.c | 469 
 drivers/gpu/drm/drm_blend.c |  23 +-
 drivers/gpu/drm/drm_plane_helper.c  |   2 +-
 drivers/gpu/drm/drm_simple_kms_helper.c |   4 +-
 include/drm/drm_atomic.h| 108 
 include/drm/drm_atomic_helper.h |  26 +-
 7 files changed, 375 insertions(+), 263 deletions(-)

-- 
2.7.4

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


[Intel-gfx] [PATCH v4 4/5] drm/atomic: Convert get_existing_state callers to get_old/new_state, v3.

2017-02-16 Thread Maarten Lankhorst
This is a straightforward conversion that converts all the users of
get_existing_state in atomic core to use get_old_state or get_new_state

Changes since v1:
- Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state.
Changes since v2:
- Use the correct state in disable_outputs()

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c|  6 ++---
 drivers/gpu/drm/drm_atomic_helper.c | 43 +
 drivers/gpu/drm/drm_blend.c |  3 +--
 drivers/gpu/drm/drm_simple_kms_helper.c |  4 +--
 4 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index afec53832145..c9aac9cbf111 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1358,8 +1358,8 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
return 0;
 
if (conn_state->crtc) {
-   crtc_state = 
drm_atomic_get_existing_crtc_state(conn_state->state,
-   
conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(conn_state->state,
+  conn_state->crtc);
 
crtc_state->connector_mask &=
~(1 << drm_connector_index(conn_state->connector));
@@ -1476,7 +1476,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
*state,
 {
struct drm_plane *plane;
 
-   WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
+   WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
 
drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
struct drm_plane_state *plane_state =
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ea544bddc29b..6296ae6e6aff 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -70,8 +70,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
struct drm_crtc_state *crtc_state;
 
if (old_plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
old_plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state,
+  
old_plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -80,8 +80,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
}
 
if (plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -150,7 +149,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
drm_for_each_connector_iter(connector, _iter) {
struct drm_crtc_state *crtc_state;
 
-   if (drm_atomic_get_existing_connector_state(state, connector))
+   if (drm_atomic_get_new_connector_state(state, connector))
continue;
 
encoder = connector->state->best_encoder;
@@ -178,7 +177,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 new_conn_state->crtc->base.id, 
new_conn_state->crtc->name,
 connector->base.id, connector->name);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
 
ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
if (ret)
@@ -219,7 +218,7 @@ set_best_encoder(struct drm_atomic_state *state,
 */
WARN_ON(!crtc && encoder != conn_state->best_encoder);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask &=
~(1 << 
drm_encoder_index(conn_state->best_encoder));
@@ -230,7 +229,7 @@ set_best_encoder(struct drm_atomic_state *state,
crtc = conn_state->crtc;
WARN_ON(!crtc);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask |=
1 << drm_encoder_index(encoder);
@@ 

[Intel-gfx] [PATCH v4 2/5] drm/atomic: Make drm_atomic_plane_disabling easier to understand.

2017-02-16 Thread Maarten Lankhorst
This function becomes a lot simpler when having passed both the old and
new state to it. Looking at all callers, it seems that old_plane_state
is never NULL so the check can be dropped.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c |  7 ---
 drivers/gpu/drm/drm_plane_helper.c  |  2 +-
 include/drm/drm_atomic_helper.h | 26 --
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7d432d9a18cf..ea544bddc29b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1757,7 +1757,8 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!funcs)
continue;
 
-   disabling = drm_atomic_plane_disabling(plane, old_plane_state);
+   disabling = drm_atomic_plane_disabling(old_plane_state,
+  new_plane_state);
 
if (active_only) {
/*
@@ -1852,11 +1853,11 @@ drm_atomic_helper_commit_planes_on_crtc(struct 
drm_crtc_state *old_crtc_state)
 
WARN_ON(plane->state->crtc && plane->state->crtc != crtc);
 
-   if (drm_atomic_plane_disabling(plane, old_plane_state) &&
+   if (drm_atomic_plane_disabling(old_plane_state, plane->state) &&
plane_funcs->atomic_disable)
plane_funcs->atomic_disable(plane, old_plane_state);
else if (plane->state->crtc ||
-drm_atomic_plane_disabling(plane, old_plane_state))
+drm_atomic_plane_disabling(old_plane_state, 
plane->state))
plane_funcs->atomic_update(plane, old_plane_state);
}
 
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 148688fb920a..f4d70dd5e3e4 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -470,7 +470,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
 * Drivers may optionally implement the ->atomic_disable callback, so
 * special-case that here.
 */
-   if (drm_atomic_plane_disabling(plane, plane_state) &&
+   if (drm_atomic_plane_disabling(plane_state, plane->state) &&
plane_funcs->atomic_disable)
plane_funcs->atomic_disable(plane, plane_state);
else
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 9ceda379ce58..dc16274987c7 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -220,10 +220,10 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
  
__drm_atomic_get_current_plane_state((crtc_state)->state, \
   plane)))
 
-/*
+/**
  * drm_atomic_plane_disabling - check whether a plane is being disabled
- * @plane: plane object
- * @old_state: previous atomic state
+ * @old_plane_state: old atomic plane state
+ * @new_plane_state: new atomic plane state
  *
  * Checks the atomic state of a plane to determine whether it's being disabled
  * or not. This also WARNs if it detects an invalid state (both CRTC and FB
@@ -233,28 +233,18 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
  * True if the plane is being disabled, false otherwise.
  */
 static inline bool
-drm_atomic_plane_disabling(struct drm_plane *plane,
-  struct drm_plane_state *old_state)
+drm_atomic_plane_disabling(struct drm_plane_state *old_plane_state,
+  struct drm_plane_state *new_plane_state)
 {
/*
 * When disabling a plane, CRTC and FB should always be NULL together.
 * Anything else should be considered a bug in the atomic core, so we
 * gently warn about it.
 */
-   WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
-   (plane->state->crtc != NULL && plane->state->fb == NULL));
+   WARN_ON((new_plane_state->crtc == NULL && new_plane_state->fb != NULL) 
||
+   (new_plane_state->crtc != NULL && new_plane_state->fb == NULL));
 
-   /*
-* When using the transitional helpers, old_state may be NULL. If so,
-* we know nothing about the current state and have to assume that it
-* might be enabled.
-*
-* When using the atomic helpers, old_state won't be NULL. Therefore
-* this check assumes that either the driver will have reconstructed
-* the correct state in ->reset() or that the driver will have taken
-* appropriate measures to disable all planes.
-*/
-   return (!old_state || old_state->crtc) && !plane->state->crtc;
+   return old_plane_state->crtc && !new_plane_state->crtc;
 }
 
 #endif /* 

  1   2   3   >