[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/bxt: Enable PSR platform support for BXT

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: Enable PSR platform support for BXT
URL   : https://patchwork.freedesktop.org/series/7675/
State : warning

== Summary ==

Series 7675v1 drm/i915/bxt: Enable PSR platform support for BXT
http://patchwork.freedesktop.org/api/1.0/series/7675/revisions/1/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test gem_basic:
Subgroup create-close:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ctx_create:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ctx_param:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:177  dwarn:6   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_999/

3a7ef25 drm-intel-nightly: 2016y-05m-24d-12h-43m-51s UTC integration manifest
1085aa4 drm/i915/bxt: Enable PSR platform support for BXT

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

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Reject modeset if the dotclock is too high

[Patchwork]

== Series Details ==

Series: drm/i915: Reject modeset if the dotclock is too high
URL   : https://patchwork.freedesktop.org/series/7653/
State : warning

== Summary ==

Series 7653v1 drm/i915: Reject modeset if the dotclock is too high
http://patchwork.freedesktop.org/api/1.0/series/7653/revisions/1/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (fi-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (fi-skl-i5-6260u)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:2   skip:38 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:167  dwarn:0   dfail:0   fail:2   skip:40 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:181  dwarn:2   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-bsw-n3050 failed to connect after reboot
fi-hsw-i7-4770k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_998/

3a7ef25 drm-intel-nightly: 2016y-05m-24d-12h-43m-51s UTC integration manifest
c2f3c3d drm/i915: Reject modeset if the dotclock is too high

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

[Intel-gfx] [PATCH] drm/i915/bxt: Enable PSR platform support for BXT

[clinton . a . taylor]

From: Clint Taylor 

Add IS_BROXTON() to the HAS_PSR() MACRO. Tested with a Sharp 2560x1440
panel that claims PSR is enable and in progress.

Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/i915_drv.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 78d38c2..1407ff1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2796,7 +2796,8 @@ struct drm_i915_cmd_table {
 #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
 #define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
 IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
-IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
+IS_SKYLAKE(dev) || IS_KABYLAKE(dev) || \
+IS_BROXTON(dev))
 #define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
 IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
 IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
-- 
1.7.9.5

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

[Intel-gfx] eDP hot plug support on i915 driver

[Sanchez, AdolfoX]

Hello

Is the eDP hotplugging capability supported by default by the intel graphic 
driver, or is it necessary any special configuration?

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

Re: [Intel-gfx] [PATCH] drm: use seqlocks for vblank time/count

[Mario Kleiner]

On 05/18/2016 05:10 PM, Matthew Auld wrote:

There's an updated version of this patch already on the ml [1], which
I Cc'd you in on. I take it that your @tuebingen.mpg.de is in fact an
old email address?

[1] https://patchwork.freedesktop.org/patch/86354/



Your patch looks good to me. I'd only keep that one dropped comment line 
in drmP.h about the vblank counter and ts also needing to be protected 
by the vblank_timelock in addition to the seqlock, as this is still 
needed, especially to get _irqsave part of spin_lock_irqsave, as the 
write seqlocks in don't do the local irq disable. I'll give it a test 
later this week.


Reviewed-by: Mario Kleiner 

Indeed the old inactive @tuebingen.mpg.de is only a forward to the gmail 
address, probably with some botched mail filter rules, so they can go 
unnoticed quite a while.


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

Re: [Intel-gfx] [PATCH v3] drm/i915/ilk: Don't disable SSC source if it's in use

[Ville Syrjälä]

On Tue, May 24, 2016 at 10:27:03AM -0400, Lyude wrote:
> Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
> 
> Unfortunately one of the sideaffects of having the refclk for a DPLL set
> to SSC is that as long as it's set to SSC, the GPU will prevent us from
> powering down any of the pipes or transcoders using it. A couple of
> BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
> configurations. This causes issues on the first modeset, since we don't
> expect SSC to be left on and as a result, can't successfully power down
> the pipes or the transcoders using it. Here's an example from this Dell
> OptiPlex 990:
> 
> [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says 
> disabled
> [drm:intel_modeset_init] 2 display pipes available.
> [drm:intel_update_cdclk] Current CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
> vgaarb: device changed decodes: 
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [drm:intel_crt_reset] crt adpa set to 0xf4
> [drm:intel_dp_init_connector] Adding DP connector on port C
> [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
> [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
> [drm:ironlake_init_pch_refclk] Disabling SSC entirely
> … later we try committing the first modeset …
> [drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for 
> pipe A
> [drm:intel_dump_pipe_config] cpu_transcoder: A
> …
> [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, 
> fp0: 0x20e08, fp1: 0x30d07
> [drm:intel_dump_pipe_config] planes on this crtc
> [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
> [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
> [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 
> 800x600
> [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, 
> scaler_id = 0
> [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, 
> scaler_id = 0
> [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
> [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
> [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
> [drm:intel_disable_pipe] disabling pipe A
> [ cut here ]
> WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 
> intel_disable_pipe+0x297/0x2d0 [i915]
> pipe_off wait timed out
> …
> ---[ end trace 94fc8aa03ae139e8 ]---
> [drm:intel_dp_link_down]
> [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
> 
> Later modesets succeed since they reset the DPLL's configuration anyway,
> but this is enough to get stuck with a big fat warning in dmesg.
> 
> A better solution would be to add refcounts for the SSC source, but for
> now leaving the source clock on should suffice.
> 
> Changes since v2:
>  - Fix debug output for when we disable the CPU source
> Changes since v1:
>  - Leave the SSC source clock on instead of just shutting it off on all
>of the DPLL configurations.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude 
> ---
> As for the diagram you mentioned feel free to add that since you probably have
> a better understanding of how that works then I do ;)
> 
>  drivers/gpu/drm/i915/intel_display.c | 47 
> +++-
>  1 file changed, 35 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d500e6f..4937b68 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8230,12 +8230,14 @@ static void ironlake_init_pch_refclk(struct 
> drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_encoder *encoder;
> - u32 val, final;
> + int i;
> + u32 val, temp, final;

'temp' is not needed outside the loop, so can be moved there.

>   bool has_lvds = false;
>   bool has_cpu_edp = false;
>   bool has_panel = false;
>   bool has_ck505 = false;
>   bool can_ssc = false;
> + bool using_ssc_source = false;
>  
>   /* We need to take the global config into account */
>   for_each_intel_encoder(dev, encoder) {
> @@ -8283,9 +8285,26 @@ static void ironlake_init_pch_refclk(struct drm_device 
> *dev)
>   else
>   final |= DREF_NONSPREAD_SOURCE_ENABLE;
>  
> - final &= ~DREF_SSC_SOURCE_MASK;
>   final &= ~DREF_CPU_SOURCE_OUTPUT_MASK;
> - final &= ~DREF_SSC1_ENABLE;
> +
> + /* Check if any DPLLs are using the SSC source */
> + for (i = 0; i < dev_priv->num_shared_dpll; i++) {
> + temp = I915_READ(PCH_DPLL(i));
> +
> + if (!(temp & DPLL_VCO_ENABLE))
> + continue;
> +
> + if ((temp & PLL_REF_INPUT_MASK) ==
> +  

[Intel-gfx] [PATCH i-g-t] tests: Add kms_invalid_dotclock

[ville . syrjala]

From: Ville Syrjälä 

Add a test that makes sure every modeset gets rejected by the kernel if
the requested dotclock is beyond the hardware capabilities.

For now we just test the preferred mode for each connector, should
perhaps test them all to be more sure everything is getting rejected.

We also skip the test on connectros that have a fixed mode as the kernel
will ignore most of the user timings. We should make the kernel more
strict I think, to at least check that the user gets roughly the refresh
rate they requeted.

Signed-off-by: Ville Syrjälä 
---
 tests/Makefile.sources   |   1 +
 tests/kms_invalid_dotclock.c | 148 +++
 2 files changed, 149 insertions(+)
 create mode 100644 tests/kms_invalid_dotclock.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c81eeeb5dbad..122b528f8dc8 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -93,6 +93,7 @@ TESTS_progs_M = \
kms_flip_event_leak \
kms_flip_tiling \
kms_frontbuffer_tracking \
+   kms_invalid_dotclock \
kms_legacy_colorkey \
kms_mmio_vs_cs_flip \
kms_pipe_b_c_ivb \
diff --git a/tests/kms_invalid_dotclock.c b/tests/kms_invalid_dotclock.c
new file mode 100644
index ..43f768fd26ea
--- /dev/null
+++ b/tests/kms_invalid_dotclock.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include 
+
+IGT_TEST_DESCRIPTION("Make sure all modesets are rejected when the requested 
dotclock is too high");
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   igt_output_t *output;
+   drmModeResPtr res;
+   int max_dotclock;
+} data_t;
+
+static bool has_scaling_mode_prop(data_t *data)
+{
+   return kmstest_get_property(data->drm_fd,
+   data->output->id,
+   DRM_MODE_OBJECT_CONNECTOR,
+   "scaling mode",
+   NULL, NULL, NULL);
+}
+
+static int
+test_output(data_t *data)
+{
+   igt_output_t *output = data->output;
+   drmModeModeInfo mode;
+   struct igt_fb fb;
+   int i;
+
+   /*
+* FIXME When we have a fixed mode, the kernel will ignore
+* the user timings apart from hdisplay/vdisplay. Should
+* fix the kernel to at least make sure the requested
+* refresh rate as specified by the user timings will
+* roughly match the user will get. For now skip the
+* test on  any connector with a fixed mode.
+*/
+   if (has_scaling_mode_prop(data))
+   return 0;
+
+   /*
+* FIXME test every mode we have to be more
+* sure everything is really getting rejected?
+*/
+   mode = *igt_output_get_mode(output);
+   mode.clock = data->max_dotclock + 1;
+
+   igt_create_fb(data->drm_fd,
+ mode.hdisplay, mode.vdisplay,
+ DRM_FORMAT_XRGB,
+ LOCAL_DRM_FORMAT_MOD_NONE,
+ );
+
+   for (i = 0; i < data->res->count_crtcs; i++) {
+   int ret;
+
+   igt_info("Checking pipe %c connector %s with mode %s\n",
+'A'+i, output->name, mode.name);
+
+   ret = drmModeSetCrtc(data->drm_fd, data->res->crtcs[i],
+fb.fb_id, 0, 0,
+>id, 1, );
+   igt_assert_lt(ret, 0);
+   }
+
+   igt_remove_fb(data->drm_fd, );
+
+   return 1;
+}
+
+static void test(data_t *data)
+{
+   int valid_connectors = 0;
+
+   for_each_connected_output(>display, data->output) {
+   valid_connectors += test_output(data);
+   }
+
+

[Intel-gfx] [PATCH] drm/i915: Reject modeset if the dotclock is too high

[ville . syrjala]

From: Ville Syrjälä 

Reject the modeset if the requested dotclock exceeds the maximum allowed
by the hardware. So far we've only checked this on gen2/3 while also
handling the double wide vs. single wide pipe selection. Extend the
check to all platforms since we have the max dotclock correctly
populated now across the board.

Testcase: igt/kms_invalid_dotclock
Cc: Mika Kahola 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1e5138497e6a..adb489508f25 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6510,10 +6510,10 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
+   int clock_limit = dev_priv->max_dotclk_freq;
 
-   /* FIXME should check pixel clock limits on all platforms */
if (INTEL_INFO(dev)->gen < 4) {
-   int clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
+   clock_limit = dev_priv->max_cdclk_freq * 9 / 10;
 
/*
 * Enable double wide mode when the dot clock
@@ -6521,16 +6521,16 @@ static int intel_crtc_compute_config(struct intel_crtc 
*crtc,
 */
if (intel_crtc_supports_double_wide(crtc) &&
adjusted_mode->crtc_clock > clock_limit) {
-   clock_limit *= 2;
+   clock_limit = dev_priv->max_dotclk_freq;
pipe_config->double_wide = true;
}
+   }
 
-   if (adjusted_mode->crtc_clock > clock_limit) {
-   DRM_DEBUG_KMS("requested pixel clock (%d kHz) too high 
(max: %d kHz, double wide: %s)\n",
- adjusted_mode->crtc_clock, clock_limit,
- yesno(pipe_config->double_wide));
-   return -EINVAL;
-   }
+   if (adjusted_mode->crtc_clock > clock_limit) {
+   DRM_DEBUG_KMS("requested pixel clock (%d kHz) too high (max: %d 
kHz, double wide: %s)\n",
+ adjusted_mode->crtc_clock, clock_limit,
+ yesno(pipe_config->double_wide));
+   return -EINVAL;
}
 
/*
-- 
2.7.4

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

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Revert async unpin and nonblocking atomic commit

[Patchwork]

== Series Details ==

Series: drm/i915: Revert async unpin and nonblocking atomic commit
URL   : https://patchwork.freedesktop.org/series/7643/
State : warning

== Summary ==

Series 7643v1 drm/i915: Revert async unpin and nonblocking atomic commit
http://patchwork.freedesktop.org/api/1.0/series/7643/revisions/1/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
fail   -> PASS   (fi-byt-n2820)
Test gem_flink_basic:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)

fi-bdw-i7-5557u  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:2   skip:38 
fi-hsw-i7-4770k  total:209  pass:190  dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:209  pass:198  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:209  pass:184  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:209  pass:170  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-byt-n2820 total:209  pass:170  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:181  dwarn:2   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-bsw-n3050 failed to connect after reboot
ro-bsw-n3050 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_997/

3a7ef25 drm-intel-nightly: 2016y-05m-24d-12h-43m-51s UTC integration manifest
1fbc385 drm/i915: Revert async unpin and nonblocking atomic commit

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

[Intel-gfx] [PATCH] drm/i915: Revert async unpin and nonblocking atomic commit

[Daniel Vetter]

This reverts the following patches:

d55dbd06bb5e1399aba9ab5227465339d1bbefff drm/i915: Allow nonblocking update of 
pageflips.
15c86bdb760185e871c7a0f559978328aa500971 drm/i915: Check for unpin correctness.
95c2ccdc82d520f59ae3b6fdc097b63c9b7082bb Reapply "drm/i915: Avoid stalling on 
pending flips for legacy cursor updates"
a6747b7304a9d66758a196d885dab8bbfa5e7d1f drm/i915: Make unpin async.
03f476e1fcb42fca88fc50b94b0d3adbdbe887f0 drm/i915: Prepare connectors for 
nonblocking checks.
2099deffef4404f949ba1b68d2b17e0608190bc2 drm/i915: Pass atomic states to fbc 
update functions.
ee7171af72c39c18b7d7571419a4ac6ca30aea66 drm/i915: Remove reset_counter from 
intel_crtc.
2ee004f7c59b2e642f0bb2834f847d756f2dd7b7 drm/i915: Remove queue_flip pointer.
b8d2afae557dbb9b9c7bc6f6ec4f5278f3c4c34e drm/i915: Remove use_mmio_flip kernel 
parameter.
8dd634d922615ec3a9af7976029110ec037f8b50 drm/i915: Remove cs based page flip 
support.
143f73b3bf48c089b40f58462dd7f7c199fd4f0f drm/i915: Rework intel_crtc_page_flip 
to be almost atomic, v3.
84fc494b64e8c591be446a966b7447a9db519c88 drm/i915: Add the exclusive fence to 
plane_state.
6885843ae164e11f6c802209d06921e678a3f3f3 drm/i915: Convert flip_work to a list.
aa420ddd8eeaa5df579894a412289e4d07c2fee9 drm/i915: Allow mmio updates on all 
platforms, v2.
afee4d8707ab1f21b7668de995be3a5961e83582 Revert "drm/i915: Avoid stalling on 
pending flips for legacy cursor updates"

"drm/i915: Allow nonblocking update of pageflips" should have been
split up, misses a proper commit message and seems to cause issues in
the legacy page_flip path as demonstrated by kms_flip.

"drm/i915: Make unpin async" doesn't handle the unthrottled cursor
updates correctly, leading to an apparent pin count leak. This is
caught by the WARN_ON in i915_gem_object_do_pin which screams if we
have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins.

Unfortuantely we can't just revert these two because this patch series
came with a built-in bisect breakage in the form of temporarily
removing the unthrottled cursor update hack for legacy cursor ioctl.
Therefore there's no other option than to revert the entire pile :(

There's one tiny conflict in intel_drv.h due to other patches, nothing
serious.

Normally I'd wait a bit longer with doing a maintainer revert, but
since the minimal set of patches we need to revert (due to the bisect
breakage) is so big, time is running out fast. And very soon
(especially after a few attempts at fixing issues) it'll be really
hard to revert things cleanly.

Lessons learned:
- Not a good idea to rush the review (done by someone fairly new to
  the area) and not make sure domain experts had a chance to read it.

- Patches should be properly split up. I only looked at the two
  patches that should be reverted in detail, but both look like the
  mix up different things in one patch.

- Patches really should have proper commit messages. Especially when
  doing more than one thing, and especially when touching critical and
  tricky core code.

- Building a patch series and r-b stamping it when it has a built-in
  bisect breakage is not a good idea.

- I also think we need to stop building up technical debt by
  postponing atomic igt testcases even longer. I think it's clear that
  there's enough corner cases in this beast that we really need to
  have the testcases _before_ the next step lands.

Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: Patrik Jakobsson 
Cc: John Harrison 
Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   89 +-
 drivers/gpu/drm/i915/i915_drv.h   |5 +
 drivers/gpu/drm/i915/i915_irq.c   |  120 +-
 drivers/gpu/drm/i915/i915_params.c|5 +
 drivers/gpu/drm/i915/i915_params.h|1 +
 drivers/gpu/drm/i915/intel_atomic.c   |   11 -
 drivers/gpu/drm/i915/intel_atomic_plane.c |1 -
 drivers/gpu/drm/i915/intel_display.c  | 1690 +++--
 drivers/gpu/drm/i915/intel_drv.h  |   43 +-
 drivers/gpu/drm/i915/intel_fbc.c  |   39 +-
 drivers/gpu/drm/i915/intel_lrc.c  |4 +-
 11 files changed, 1333 insertions(+), 675 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b29ba16c90b3..ac7e5692496d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -621,52 +621,6 @@ static int i915_gem_gtt_info(struct seq_file *m, void 
*data)
return 0;
 }
 
-static void i915_dump_pageflip(struct seq_file *m,
-  struct drm_i915_private *dev_priv,
-  struct intel_crtc *crtc,
-  struct intel_flip_work *work)
-{
-   const char pipe = pipe_name(crtc->pipe);
-   u32 pending;
-   int i;
-
-  

Re: [Intel-gfx] [PATCH i-g-t] tests/Android.mk: Update cairo dependant test list

[Marius Vlad]

Applied, thanks!
On Tue, May 24, 2016 at 03:32:35PM +0100, Derek Morton wrote:
> drm_read
> gem_exec_blt
> prime_mmap_kms
> Have cairo dependency through igt_kms.c so add to skip_tests_list
> to fix android build errors.
> 
> Signed-off-by: Derek Morton 
> ---
>  tests/Android.mk | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/Android.mk b/tests/Android.mk
> index 8457125..3186a2a 100644
> --- a/tests/Android.mk
> +++ b/tests/Android.mk
> @@ -56,7 +56,10 @@ else
>  # the following tests depend on cairo, so skip them
>  skip_tests_list += \
>  gem_render_copy \
> -pm_lpsp
> +pm_lpsp \
> + drm_read \
> + gem_exec_blt \
> + prime_mmap_kms
>  
>  # All kms tests depend on cairo
>  tmp_list := $(foreach test_name, $(TESTS_progs),\
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

Re: [Intel-gfx] [RFC i-g-t 1/9] configure.ac: Test for libdrm_intel and build for it if present.

[Robert Foss]

On 2016-05-23 11:03 AM, Emil Velikov wrote:

On Saturday, May 21, 2016 08:55 BST, Chris Wilson  
wrote:

On Fri, May 20, 2016 at 06:59:25PM -0400, robert.f...@collabora.com wrote:

From: Robert Foss 

Test for libdrm_intel and build for it if present.
Also expose the HAVE_INTEL #define to allow code to be conditionally
compiled.

Signed-off-by: Robert Foss 
---
  configure.ac | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 0589782..b6fc168 100644
--- a/configure.ac
+++ b/configure.ac
@@ -100,7 +100,7 @@ if test "x$GCC" = "xyes"; then
  fi
  AC_SUBST(ASSEMBLER_WARN_CFLAGS)

-PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.64 libdrm])
+PKG_CHECK_MODULES(DRM, [libdrm])
  PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])

  case "$target_cpu" in
@@ -150,6 +150,18 @@ PKG_CHECK_MODULES(GLIB, glib-2.0)
  # 
-
  # Configuration options
  # 
-
+AC_ARG_ENABLE(intel, AS_HELP_STRING([--disable-intel],
+ [Enable building of intel specific parts (default: auto)]),
+ [INTEL=$enableval], [INTEL=auto])
+if test "x$INTEL" = xauto; then
+   PKG_CHECK_EXISTS([libdrm_intel >= 2.4.64], [INTEL=yes], [INTEL=no])
+fi
+if test "x$INTEL" = xyes; then
+   PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])



+   AC_DEFINE(HAVE_INTEL, 1, [Have intel support])
+fi
+AM_CONDITIONAL(HAVE_INTEL, [test "x$INTEL" = xyes])


HAVE_INTEL caused quite a bit of confusion when reading the later build
patches.

Please use HAVE_LIBDRM_INTEL instead

As a counter argument, one could, should really, use --enable-intel to replace 
the 'x86' parts in commit bccc0ec6a3fdae880e14770c2ff5770fb86ea6fc. Perhaps 
HAVE_INTEL isn't that bad when we take that into consideration ?



The purpose of HAVE_INTEL isn't really to avoid building x86 code on 
non-x86 platforms, but rather to avoid a build dependency where it can 
be avoided.


That being said using a BUILD_X86 or something like it to avoid building 
irrelevant binaries would be very useful.


Either way, HAVE_LIBDRM_INTEL more clearly defines what the flag is about.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: use seqlock for vblank time/count

[Daniel Vetter]

On Tue, May 24, 2016 at 03:20:54PM +0300, Ville Syrjälä wrote:
> On Tue, May 10, 2016 at 03:21:28PM +0100, Matthew Auld wrote:
> > This patch aims to replace the roll-your-own seqlock implementation with
> > full-blown seqlock'. We also remove the timestamp ring-buffer in favour
> > of single timestamp/count pair protected by a seqlock. In turn this
> > means we can now increment the vblank freely without the need for
> > clamping.
> > 
> > v2:
> >   - reduce the scope of the seqlock, keeping vblank_time_lock
> >   - make the seqlock per vblank_crtc, so multiple readers aren't blocked by
> > the writer
> > 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Matthew Auld 
> 
> LGTM
> 
> Reviewed-by: Ville Syrjälä 

Applied to drm-misc, thanks.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 90 
> > +++
> >  include/drm/drmP.h| 14 +++-
> >  2 files changed, 17 insertions(+), 87 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 3c1a6f1..0e95100 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -42,10 +42,6 @@
> >  #include 
> >  #include 
> >  
> > -/* Access macro for slots in vblank timestamp ringbuffer. */
> > -#define vblanktimestamp(dev, pipe, count) \
> > -   ((dev)->vblank[pipe].time[(count) % DRM_VBLANKTIME_RBSIZE])
> > -
> >  /* Retry timestamp calculation up to 3 times to satisfy
> >   * drm_timestamp_precision before giving up.
> >   */
> > @@ -82,29 +78,15 @@ static void store_vblank(struct drm_device *dev, 
> > unsigned int pipe,
> >  struct timeval *t_vblank, u32 last)
> >  {
> > struct drm_vblank_crtc *vblank = >vblank[pipe];
> > -   u32 tslot;
> >  
> > assert_spin_locked(>vblank_time_lock);
> >  
> > vblank->last = last;
> >  
> > -   /* All writers hold the spinlock, but readers are serialized by
> > -* the latching of vblank->count below.
> > -*/
> > -   tslot = vblank->count + vblank_count_inc;
> > -   vblanktimestamp(dev, pipe, tslot) = *t_vblank;
> > -
> > -   /*
> > -* vblank timestamp updates are protected on the write side with
> > -* vblank_time_lock, but on the read side done locklessly using a
> > -* sequence-lock on the vblank counter. Ensure correct ordering using
> > -* memory barrriers. We need the barrier both before and also after the
> > -* counter update to synchronize with the next timestamp write.
> > -* The read-side barriers for this are in drm_vblank_count_and_time.
> > -*/
> > -   smp_wmb();
> > +   write_seqlock(>seqlock);
> > +   vblank->time = *t_vblank;
> > vblank->count += vblank_count_inc;
> > -   smp_wmb();
> > +   write_sequnlock(>seqlock);
> >  }
> >  
> >  /**
> > @@ -205,7 +187,7 @@ static void drm_update_vblank_count(struct drm_device 
> > *dev, unsigned int pipe,
> > const struct timeval *t_old;
> > u64 diff_ns;
> >  
> > -   t_old = (dev, pipe, vblank->count);
> > +   t_old = >time;
> > diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old);
> >  
> > /*
> > @@ -239,49 +221,6 @@ static void drm_update_vblank_count(struct drm_device 
> > *dev, unsigned int pipe,
> > diff = 1;
> > }
> >  
> > -   /*
> > -* FIMXE: Need to replace this hack with proper seqlocks.
> > -*
> > -* Restrict the bump of the software vblank counter to a safe maximum
> > -* value of +1 whenever there is the possibility that concurrent readers
> > -* of vblank timestamps could be active at the moment, as the current
> > -* implementation of the timestamp caching and updating is not safe
> > -* against concurrent readers for calls to store_vblank() with a bump
> > -* of anything but +1. A bump != 1 would very likely return corrupted
> > -* timestamps to userspace, because the same slot in the cache could
> > -* be concurrently written by store_vblank() and read by one of those
> > -* readers without the read-retry logic detecting the collision.
> > -*
> > -* Concurrent readers can exist when we are called from the
> > -* drm_vblank_off() or drm_vblank_on() functions and other non-vblank-
> > -* irq callers. However, all those calls to us are happening with the
> > -* vbl_lock locked to prevent drm_vblank_get(), so the vblank refcount
> > -* can't increase while we are executing. Therefore a zero refcount at
> > -* this point is safe for arbitrary counter bumps if we are called
> > -* outside vblank irq, a non-zero count is not 100% safe. Unfortunately
> > -* we must also accept a refcount of 1, as whenever we are called from
> > -* drm_vblank_get() -> drm_vblank_enable() the refcount will be 1 and
> > -* we must let that one pass through in order to not lose vblank counts
> > -   

Re: [Intel-gfx] [PATCH i-g-t] tests: Moved gem_concurrent_blit back to the normal set

[Marius Vlad]

Applied.

On Tue, May 17, 2016 at 03:05:47PM +0300, Gabriel Feceoru wrote:
> Repairing the damage I caused not reading properly Daniel's comment in:
> https://patchwork.freedesktop.org/patch/81600/
> 
> Leaving gem_concurrent_all only in the EXTRA set
> 
> Cc: Daniel Vetter 
> Cc: Marius Vlad 
> Signed-off-by: Gabriel Feceoru 
> ---
>  tests/Makefile.sources | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 7b5f316..81d0a55 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -20,6 +20,7 @@ TESTS_progs_M = \
>   gem_busy \
>   gem_caching \
>   gem_close_race \
> + gem_concurrent_blit \
>   gem_create \
>   gem_cs_tlb \
>   gem_ctx_bad_exec \
> @@ -119,7 +120,6 @@ TESTS_progs_M = \
>   $(NULL)
>  
>  TESTS_progs_XM = \
> -gem_concurrent_blit \
>  gem_concurrent_all \
>  $(NULL)
>  
> -- 
> 1.9.1
> 


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

Re: [Intel-gfx] [PATCH i-g-t] tests/Android.mk: Update cairo dependant test list

[Gore, Tim]

Tim Gore 
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ


> -Original Message-
> From: Morton, Derek J
> Sent: Tuesday, May 24, 2016 3:33 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Gore, Tim; Morton, Derek J
> Subject: [PATCH i-g-t] tests/Android.mk: Update cairo dependant test list
> 
> drm_read
> gem_exec_blt
> prime_mmap_kms
> Have cairo dependency through igt_kms.c so add to skip_tests_list to fix
> android build errors.
> 
> Signed-off-by: Derek Morton 
> ---
>  tests/Android.mk | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/Android.mk b/tests/Android.mk index 8457125..3186a2a
> 100644
> --- a/tests/Android.mk
> +++ b/tests/Android.mk
> @@ -56,7 +56,10 @@ else
>  # the following tests depend on cairo, so skip them
>  skip_tests_list += \
>  gem_render_copy \
> -pm_lpsp
> +pm_lpsp \
> + drm_read \
> + gem_exec_blt \
> + prime_mmap_kms
> 
>  # All kms tests depend on cairo
>  tmp_list := $(foreach test_name, $(TESTS_progs),\
> --
> 1.9.1

Works for me.

Reviewed-by: Tim Gore 


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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume

[Ville Syrjälä]

On Tue, May 24, 2016 at 03:38:33PM +0300, Imre Deak wrote:
> I noticed that during S4 resume BIOS incorrectly sets bits 18, 19 which
> are reserved/MBZ and sets the decimal frequency fields to all 0xff in
> the CDCLK register. The result is a hard lockup as display register
> accesses are attempted later. Work around this by sanitizing the CDCLK
> PLL/dividers the same way it's done on SKL.
> 
> While this is clearly a BIOS bug which should be fixed separately, it
> doesn't hurt to check/sanitize this regardless.
> 
> v2:
> - Use the same condition for VCO and CDCLK in broxton_init_cdclk as is
>   used in skl_init_cdclk for the same purpose.
> 
> CC: Ville Syrjälä 
> Signed-off-by: Imre Deak 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 51 
> ++--
>  1 file changed, 49 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 47b2466..19f947f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5412,11 +5412,58 @@ static void broxton_set_cdclk(struct drm_i915_private 
> *dev_priv, int cdclk)
>   intel_update_cdclk(dev_priv->dev);
>  }
>  
> +static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
> +{
> + u32 cdctl, expected;
> +
> + intel_update_cdclk(dev_priv->dev);
> +
> + if (dev_priv->cdclk_pll.vco == 0 ||
> + dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
> + goto sanitize;
> +
> + /* DPLL okay; verify the cdclock
> +  *
> +  * Some BIOS versions leave an incorrect decimal frequency value and
> +  * set reserved MBZ bits in CDCLK_CTL at least during exiting from S4,
> +  * so sanitize this register.
> +  */
> + cdctl = I915_READ(CDCLK_CTL);
> + /*
> +  * Let's ignore the pipe field, since BIOS could have configured the
> +  * dividers both synching to an active pipe, or asynchronously
> +  * (PIPE_NONE).
> +  */
> + cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
> +
> + expected = (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) |
> +skl_cdclk_decimal(dev_priv->cdclk_freq);
> + /*
> +  * Disable SSA Precharge when CD clock frequency < 500 MHz,
> +  * enable otherwise.
> +  */
> + if (dev_priv->cdclk_freq >= 50)
> + expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
> +
> + if (cdctl == expected)
> + /* All well; nothing to sanitize */
> + return;
> +
> +sanitize:
> + DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
> +
> + /* force cdclk programming */
> + dev_priv->cdclk_freq = 0;
> +
> + /* force full PLL disable + enable */
> + dev_priv->cdclk_pll.vco = -1;
> +}
> +
>  void broxton_init_cdclk(struct drm_i915_private *dev_priv)
>  {
> - intel_update_cdclk(dev_priv->dev);
> + bxt_sanitize_cdclk(dev_priv);
>  
> - if (dev_priv->cdclk_pll.vco != 0)
> + if (dev_priv->cdclk_freq != 0 && dev_priv->cdclk_pll.vco != 0)
>   return;
>  
>   /*
> -- 
> 2.5.0

-- 
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 v2 1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Ville Syrjälä]

On Tue, May 24, 2016 at 03:38:32PM +0300, Imre Deak wrote:
> If the CDCLK PLL isn't locked or incorrectly configured we can just
> assume that it's off resulting in fully re-initializing both CDCLK PLL
> and CDCLK dividers. This way the CDCLK PLL sanitization added in the
> following patch can be done on BXT the same way as it's done on SKL.
> 
> v2: (Ville)
> - Remove the remaining PLL specific checks from skl_sanitize_cdclk() and
>   depend instead on the corresponding check in skl_dpll0_update().
> - Use vco == 0 instead of the corresponding boolean check in
>   skl_sanitize_cdclk().
> 
> CC: Ville Syrjälä 
> Signed-off-by: Imre Deak 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 39 
> +++-
>  1 file changed, 16 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c1e666b..47b2466 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5461,21 +5461,22 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
>   u32 val;
>  
>   dev_priv->cdclk_pll.ref = 24000;
> + dev_priv->cdclk_pll.vco = 0;
>  
>   val = I915_READ(LCPLL1_CTL);
> - if ((val & LCPLL_PLL_ENABLE) == 0) {
> - dev_priv->cdclk_pll.vco = 0;
> + if ((val & LCPLL_PLL_ENABLE) == 0)
>   return;
> - }
>  
> - WARN_ON((val & LCPLL_PLL_LOCK) == 0);
> + if (WARN_ON((val & LCPLL_PLL_LOCK) == 0))
> + return;
>  
>   val = I915_READ(DPLL_CTRL1);
>  
> - WARN_ON((val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
> - DPLL_CTRL1_SSC(SKL_DPLL0) |
> - DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
> - DPLL_CTRL1_OVERRIDE(SKL_DPLL0));
> + if (WARN_ON((val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
> + DPLL_CTRL1_SSC(SKL_DPLL0) |
> + DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
> + DPLL_CTRL1_OVERRIDE(SKL_DPLL0)))
> + return;
>  
>   switch (val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0)) {
>   case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, SKL_DPLL0):
> @@ -5490,7 +5491,6 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
>   break;
>   default:
>   MISSING_CASE(val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0));
> - dev_priv->cdclk_pll.vco = 0;
>   break;
>   }
>  }
> @@ -5690,19 +5690,12 @@ static void skl_sanitize_cdclk(struct 
> drm_i915_private *dev_priv)
>   if ((I915_READ(SWF_ILK(0x18)) & 0x00FF) == 0)
>   goto sanitize;
>  
> + intel_update_cdclk(dev_priv->dev);
>   /* Is PLL enabled and locked ? */
> - if ((I915_READ(LCPLL1_CTL) & (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK)) !=
> - (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK))
> + if (dev_priv->cdclk_pll.vco == 0 ||
> + dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
>   goto sanitize;
>  
> - if ((I915_READ(DPLL_CTRL1) & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
> -   DPLL_CTRL1_SSC(SKL_DPLL0) |
> -   DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
> - DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
> - goto sanitize;
> -
> - intel_update_cdclk(dev_priv->dev);
> -
>   /* DPLL okay; verify the cdclock
>*
>* Noticed in some instances that the freq selection is correct but
> @@ -6608,14 +6601,14 @@ static void bxt_de_pll_update(struct drm_i915_private 
> *dev_priv)
>   u32 val;
>  
>   dev_priv->cdclk_pll.ref = 19200;
> + dev_priv->cdclk_pll.vco = 0;
>  
>   val = I915_READ(BXT_DE_PLL_ENABLE);
> - if ((val & BXT_DE_PLL_PLL_ENABLE) == 0) {
> - dev_priv->cdclk_pll.vco = 0;
> + if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
>   return;
> - }
>  
> - WARN_ON((val & BXT_DE_PLL_LOCK) == 0);
> + if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
> + return;
>  
>   val = I915_READ(BXT_DE_PLL_CTL);
>   dev_priv->cdclk_pll.vco = (val & BXT_DE_PLL_RATIO_MASK) *
> -- 
> 2.5.0

-- 
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 v2 1/4] drm/i915: Wait for flips to complete before returning.

[Daniel Vetter]

On Tue, May 24, 2016 at 01:24:08PM +0200, Maarten Lankhorst wrote:
> Doing a page flip right after setcrtc would fail because part of the update 
> is run
> asynchronously. This is a regression and is causing the kms_flip to fails 
> after
> reverting the atomic page flip patch.

How exactly does it fail? What's the error output from igt? Which testcase
exactly goes boom? What else is on fire when running full kms_flip?

I know you don't like typing docs and commit message, and I'm not too
happy with the terseness in general from your commits. But when the
fireworks show is happening, it really needs to be a full in-depth story
and not the just 2 sentence summary from the bestseller list.
-Daniel

> 
> Signed-off-by: Maarten Lankhorst 
> Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
> ---
>  drivers/gpu/drm/i915/intel_display.c | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a500f08ec0ac..21c0a2f3102b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3788,7 +3788,7 @@ static void page_flip_completed(struct intel_crtc 
> *intel_crtc, struct intel_flip
>   queue_work(dev_priv->wq, >unpin_work);
>  }
>  
> -static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
> +static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc, bool 
> intr)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -3796,10 +3796,15 @@ static int intel_crtc_wait_for_pending_flips(struct 
> drm_crtc *crtc)
>  
>   WARN_ON(waitqueue_active(_priv->pending_flip_queue));
>  
> - ret = wait_event_interruptible_timeout(
> - dev_priv->pending_flip_queue,
> - !intel_crtc_has_pending_flip(crtc),
> - 60*HZ);
> + if (intr)
> + ret = wait_event_interruptible_timeout(
> + dev_priv->pending_flip_queue,
> + 
> !intel_crtc_has_pending_flip(crtc),
> + 60*HZ);
> + else
> + ret = wait_event_timeout(dev_priv->pending_flip_queue,
> +  !intel_crtc_has_pending_flip(crtc),
> +  60*HZ);
>  
>   if (ret < 0)
>   return ret;
> @@ -12736,7 +12741,7 @@ static int intel_atomic_prepare_commit(struct 
> drm_device *dev,
>   struct intel_flip_work *work;
>  
>   if (!state->legacy_cursor_update) {
> - ret = intel_crtc_wait_for_pending_flips(crtc);
> + ret = intel_crtc_wait_for_pending_flips(crtc, true);
>   if (ret)
>   return ret;
>  
> @@ -13005,6 +13010,7 @@ static int intel_atomic_commit(struct drm_device *dev,
>   struct drm_crtc_state *old_crtc_state;
>   struct drm_crtc *crtc;
>   int ret = 0, i;
> + unsigned crtc_mask = 0;
>  
>   ret = intel_atomic_prepare_commit(dev, state, nonblock);
>   if (ret) {
> @@ -13075,6 +13081,8 @@ static int intel_atomic_commit(struct drm_device *dev,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   bool modeset = needs_modeset(crtc->state);
>  
> + crtc_mask |= drm_crtc_mask(crtc);
> +
>   if (modeset && crtc->state->active) {
>   update_scanline_offset(to_intel_crtc(crtc));
>   dev_priv->display.crtc_enable(crtc);
> @@ -13105,6 +13113,12 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>   intel_schedule_update(crtc, intel_state, work, nonblock);
>   }
>  
> + if (!nonblock && !state->legacy_cursor_update) {
> + drm_for_each_crtc(crtc, dev)
> + if (crtc_mask & drm_crtc_mask(crtc))
> + intel_crtc_wait_for_pending_flips(crtc, false);
> + }
> +
>   /* FIXME: add subpixel order */
>  
>   drm_atomic_state_free(state);
> -- 
> 2.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/Android.mk: Update cairo dependant test list

[Derek Morton]

drm_read
gem_exec_blt
prime_mmap_kms
Have cairo dependency through igt_kms.c so add to skip_tests_list
to fix android build errors.

Signed-off-by: Derek Morton 
---
 tests/Android.mk | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/Android.mk b/tests/Android.mk
index 8457125..3186a2a 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -56,7 +56,10 @@ else
 # the following tests depend on cairo, so skip them
 skip_tests_list += \
 gem_render_copy \
-pm_lpsp
+pm_lpsp \
+   drm_read \
+   gem_exec_blt \
+   prime_mmap_kms
 
 # All kms tests depend on cairo
 tmp_list := $(foreach test_name, $(TESTS_progs),\
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Bump pin_count to 255.

[Daniel Vetter]

On Tue, May 24, 2016 at 01:24:09PM +0200, Maarten Lankhorst wrote:
> With nonblocking unpin there can be many cursor pins before they're
> cleared by the next page flip.
> 
> Fix this by extending pin_count to 255 to prevent a
> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
> 
> Cc: Ville Syrjälä 
> Reported-by: Chris Wilson 
> Signed-off-by: Maarten Lankhorst 
> Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 62be77cac5cd..bb53c285eef7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -218,8 +218,8 @@ struct i915_vma {
>*
>* In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
>* bits with absolutely no headroom. So use 4 bits. */
> - unsigned int pin_count:4;
> -#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 0xf
> + unsigned int pin_count;
> +#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 255

Nack. We can't just leak all over the place imo, so if this is the fix it
needs a _much_ better explanation for why it happens now, why it's
inevitable, why there's no better fix, what other fixes have been
considered and why a revert of the offending patch is not the better
course of action.
-Daneil

>  };
>  
>  struct i915_page_dma {
> -- 
> 2.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915/ilk: Don't disable SSC source if it's in use

[Lyude]

Thanks to Ville Syrjälä for pointing me towards the cause of this issue.

Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
configurations. This causes issues on the first modeset, since we don't
expect SSC to be left on and as a result, can't successfully power down
the pipes or the transcoders using it. Here's an example from this Dell
OptiPlex 990:

[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf4
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
… later we try committing the first modeset …
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for 
pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
…
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, 
fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, 
scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, 
scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
[ cut here ]
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 
intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
…
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A

Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.

A better solution would be to add refcounts for the SSC source, but for
now leaving the source clock on should suffice.

Changes since v2:
 - Fix debug output for when we disable the CPU source
Changes since v1:
 - Leave the SSC source clock on instead of just shutting it off on all
   of the DPLL configurations.

Cc: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
As for the diagram you mentioned feel free to add that since you probably have
a better understanding of how that works then I do ;)

 drivers/gpu/drm/i915/intel_display.c | 47 +++-
 1 file changed, 35 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d500e6f..4937b68 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8230,12 +8230,14 @@ static void ironlake_init_pch_refclk(struct drm_device 
*dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
-   u32 val, final;
+   int i;
+   u32 val, temp, final;
bool has_lvds = false;
bool has_cpu_edp = false;
bool has_panel = false;
bool has_ck505 = false;
bool can_ssc = false;
+   bool using_ssc_source = false;
 
/* We need to take the global config into account */
for_each_intel_encoder(dev, encoder) {
@@ -8283,9 +8285,26 @@ static void ironlake_init_pch_refclk(struct drm_device 
*dev)
else
final |= DREF_NONSPREAD_SOURCE_ENABLE;
 
-   final &= ~DREF_SSC_SOURCE_MASK;
final &= ~DREF_CPU_SOURCE_OUTPUT_MASK;
-   final &= ~DREF_SSC1_ENABLE;
+
+   /* Check if any DPLLs are using the SSC source */
+   for (i = 0; i < dev_priv->num_shared_dpll; i++) {
+   temp = I915_READ(PCH_DPLL(i));
+
+   if (!(temp & DPLL_VCO_ENABLE))
+   continue;
+
+   if ((temp & PLL_REF_INPUT_MASK) ==
+   PLLB_REF_INPUT_SPREADSPECTRUMIN) {
+   using_ssc_source = true;
+   break;
+   }
+   }
+
+   if (!using_ssc_source) {
+   final &= ~DREF_SSC_SOURCE_MASK;
+   final &= ~DREF_SSC1_ENABLE;
+   }
 
if 

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [v2,01/11] drm/i915: Rename struct intel_context (rev10)

[Patchwork]

== Series Details ==

Series: series starting with [v2,01/11] drm/i915: Rename struct intel_context 
(rev10)
URL   : https://patchwork.freedesktop.org/series/7564/
State : warning

== Summary ==

Series 7564v10 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7564/revisions/10/mbox

Test drv_module_reload_basic:
skip   -> PASS   (ro-ivb-i7-3770)
Test gem_busy:
Subgroup basic-parallel-blt:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_basic:
Subgroup readonly-render:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_sink_crc_basic:
pass   -> SKIP   (ro-skl-i7-6700hq)
Test pm_rps:
Subgroup basic-api:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:178  dwarn:4   dfail:0   fail:0   skip:22 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_995/

3a7ef25 drm-intel-nightly: 2016y-05m-24d-12h-43m-51s UTC integration manifest
ec465c9 drm/i915/debugfs: Show context objects in i915_gem_objects
d9891a5 drm/i915: Rearrange i915_gem_context
1acdd6e drm/i915: Merge legacy+execlists context structs
23c3b42 drm/i915: Put the kernel_context in drm_i915_private next to its friends
49c2c78 drm/i915: Show i915_gem_context owner in debugfs
3f52ed9 drm/i915: Move pinning of dev_priv->kernel_context into its creator
685ca45 drm/i915: Name the inner most per-engine intel_context struct
746bc44 drm/i915: Rename and inline i915_gem_context_get()
5224ddc drm/i915: Apply lockdep annotations to i915_gem_context.c
3da12fa drm/i915: Rename struct intel_context

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

Re: [Intel-gfx] [PATCH v2] drm/i915/ilk: Don't disable SSC source if it's in use

[Lyude Paul]

Huh… so I'm going to have to take back what I said before about this. On further
observation, it looks like the "Don't disable SSC source if it's in use" patch
actually got rid of the underruns entirely, with or without the wait for a
vblank here.

On Tue, 2016-05-24 at 16:14 +0300, Ville Syrjälä wrote:
> On Mon, May 23, 2016 at 03:56:36PM -0400, Lyude wrote:
> > 
> > Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
> > 
> > Unfortunately one of the sideaffects of having the refclk for a DPLL set
> > to SSC is that as long as it's set to SSC, the GPU will prevent us from
> > powering down any of the pipes or transcoders using it. A couple of
> > BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
> > configurations. This causes issues on the first modeset, since we don't
> > expect SSC to be left on and as a result, can't successfully power down
> > the pipes or the transcoders using it. Here's an example from this Dell
> > OptiPlex 990:
> > 
> > [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says
> > disabled
> > [drm:intel_modeset_init] 2 display pipes available.
> > [drm:intel_update_cdclk] Current CD clock rate: 40 kHz
> > [drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
> > [drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
> > vgaarb: device changed decodes:
> > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> > [drm:intel_crt_reset] crt adpa set to 0xf4
> > [drm:intel_dp_init_connector] Adding DP connector on port C
> > [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
> > [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
> > [drm:ironlake_init_pch_refclk] Disabling SSC entirely
> > … later we try committing the first modeset …
> > [drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for
> > pipe A
> > [drm:intel_dump_pipe_config] cpu_transcoder: A
> > …
> > [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0,
> > fp0: 0x20e08, fp1: 0x30d07
> > [drm:intel_dump_pipe_config] planes on this crtc
> > [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
> > [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
> > [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0)
> > 800x600
> > [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled,
> > scaler_id = 0
> > [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled,
> > scaler_id = 0
> > [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
> > [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
> > [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
> > [drm:intel_disable_pipe] disabling pipe A
> > [ cut here ]
> > WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146
> > intel_disable_pipe+0x297/0x2d0 [i915]
> > pipe_off wait timed out
> > …
> > ---[ end trace 94fc8aa03ae139e8 ]---
> > [drm:intel_dp_link_down]
> > [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
> > 
> > Later modesets succeed since they reset the DPLL's configuration anyway,
> > but this is enough to get stuck with a big fat warning in dmesg.
> > 
> > A better solution would be to add refcounts for the SSC source, but for
> > now leaving the source clock on should suffice.
> > 
> > Changes since v1:
> >  - Leave the SSC source clock on instead of just shutting it off on all
> >    of the DPLL configurations.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Lyude 
> > ---
> > Sorry about that! I misread danvet's suggestion as "disable the SSC" instead
> > of
> > "don't disable the SSC".
> > 
> >  drivers/gpu/drm/i915/intel_display.c | 47 +++
> > -
> >  1 file changed, 35 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d500e6f..dff8511 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8230,12 +8230,14 @@ static void ironlake_init_pch_refclk(struct
> > drm_device *dev)
> >  {
> >     struct drm_i915_private *dev_priv = dev->dev_private;
> >     struct intel_encoder *encoder;
> > -   u32 val, final;
> > +   int i;
> > +   u32 val, temp, final;
> >     bool has_lvds = false;
> >     bool has_cpu_edp = false;
> >     bool has_panel = false;
> >     bool has_ck505 = false;
> >     bool can_ssc = false;
> > +   bool using_ssc_source = false;
> >  
> >     /* We need to take the global config into account */
> >     for_each_intel_encoder(dev, encoder) {
> > @@ -8283,9 +8285,26 @@ static void ironlake_init_pch_refclk(struct
> > drm_device *dev)
> >     else
> >     final |= DREF_NONSPREAD_SOURCE_ENABLE;
> >  
> > -   final &= ~DREF_SSC_SOURCE_MASK;
> >     final &= ~DREF_CPU_SOURCE_OUTPUT_MASK;
> > -   final &= ~DREF_SSC1_ENABLE;
> > +
> > +   

Re: [Intel-gfx] [PATCH v2 18/21] drm/i915: Make unpin async.

[Daniel Vetter]

On Tue, May 17, 2016 at 03:08:01PM +0200, Maarten Lankhorst wrote:
> All of intel_post_plane_update is handled there now, so move it over.
> This is run after the hw state checker because it can't handle checking
> crtc's separately yet.
> 
> Signed-off-by: Maarten Lankhorst 

First this patch is massive, and imo too big and should have been split
up.

> ---
>  drivers/gpu/drm/i915/intel_atomic.c  |  11 ++
>  drivers/gpu/drm/i915/intel_display.c | 344 
> ++-
>  drivers/gpu/drm/i915/intel_drv.h |   5 +-
>  3 files changed, 228 insertions(+), 132 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 50ff90aea721..b4927f6bbeac 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -311,6 +311,17 @@ intel_atomic_state_alloc(struct drm_device *dev)
>  void intel_atomic_state_clear(struct drm_atomic_state *s)
>  {
>   struct intel_atomic_state *state = to_intel_atomic_state(s);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(state->work); i++) {
> + struct intel_flip_work *work = state->work[i];
> +
> + if (work)
> + intel_free_flip_work(work);
> +
> + state->work[i] = NULL;
> + }
> +
>   drm_atomic_state_default_clear(>base);
>   state->dpll_set = state->modeset = false;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 69abc808a2c4..16d8e24d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4537,39 +4537,6 @@ intel_pre_disable_primary_noatomic(struct drm_crtc 
> *crtc)
>   }
>  }
>  
> -static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
> -{
> - struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> - struct drm_atomic_state *old_state = old_crtc_state->base.state;
> - struct intel_crtc_state *pipe_config =
> - to_intel_crtc_state(crtc->base.state);
> - struct drm_device *dev = crtc->base.dev;
> - struct drm_plane *primary = crtc->base.primary;
> - struct drm_plane_state *old_pri_state =
> - drm_atomic_get_existing_plane_state(old_state, primary);
> -
> - intel_frontbuffer_flip(dev, pipe_config->fb_bits);
> -
> - crtc->wm.cxsr_allowed = true;
> -
> - if (pipe_config->update_wm_post && pipe_config->base.active)
> - intel_update_watermarks(>base);
> -
> - if (old_pri_state) {
> - struct intel_plane_state *primary_state =
> - to_intel_plane_state(primary->state);
> - struct intel_plane_state *old_primary_state =
> - to_intel_plane_state(old_pri_state);
> -
> - intel_fbc_post_update(crtc);
> -
> - if (primary_state->visible &&
> - (needs_modeset(_config->base) ||
> -  !old_primary_state->visible))
> - intel_post_enable_primary(>base);
> - }
> -}

The above seems to have moved/disappeared entirely, and is definitely not
unpin related. Really, this must be split up. I guess another reason to
revert this for now.

Or at least the commit should have a more accurate summary. But since I
can't even find the new callsite of these functions in this diff here
something seems fishy, but I didn't look at the entire series.

Anyway, with that rant out of the way see below for what I really wanted
to comment on.


[snip]

> +static void intel_prepare_work(struct drm_crtc *crtc,
> +struct intel_flip_work *work,
> +struct drm_atomic_state *state,
> +struct drm_crtc_state *old_crtc_state)
>  {
> - unsigned last_vblank_count[I915_MAX_PIPES];
> - enum pipe pipe;
> - int ret;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct drm_plane_state *old_plane_state;
> + struct drm_plane *plane;
> + int i, j = 0;
>  
> - if (!crtc_mask)
> - return;
> + INIT_WORK(>unpin_work, intel_unpin_work_fn);
> + INIT_WORK(>mmio_work, intel_mmio_flip_work_func);
> + atomic_inc(_crtc->unpin_work_count);
>  
> - for_each_pipe(dev_priv, pipe) {
> - struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> + for_each_plane_in_state(state, plane, old_plane_state, i) {
> + struct intel_plane_state *old_state = 
> to_intel_plane_state(old_plane_state);
> + struct intel_plane_state *new_state = 
> to_intel_plane_state(plane->state);
>  
> - if (!((1 << pipe) & crtc_mask))
> + if (old_state->base.crtc != crtc &&
> + new_state->base.crtc != crtc)
>   continue;
>  
> - ret = drm_crtc_vblank_get(crtc);
> - if (WARN_ON(ret != 0)) {
> - 

[Intel-gfx] [CI 08/10] drm/i915: Merge legacy+execlists context structs

[Chris Wilson]

struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.

v2: Only pin the default context for legacy mode (the object only exists
for legacy, but adding i915.enable_execlists provides symmetry with the
cleanup functions).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 41 +-
 drivers/gpu/drm/i915/i915_drv.h |  7 ---
 drivers/gpu/drm/i915/i915_gem_context.c | 75 +++--
 drivers/gpu/drm/i915/intel_lrc.c| 26 
 drivers/gpu/drm/i915/intel_lrc.h|  1 -
 5 files changed, 55 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e81b795005b9..95a871b8f379 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,13 +199,6 @@ describe_obj(struct seq_file *m, struct 
drm_i915_gem_object *obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
 }
 
-static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
-{
-   seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
-   seq_putc(m, ctx->remap_slice ? 'R' : 'r');
-   seq_putc(m, ' ');
-}
-
 static int i915_gem_object_list_info(struct seq_file *m, void *data)
 {
struct drm_info_node *node = m->private;
@@ -2001,7 +1994,6 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
-   enum intel_engine_id id;
int ret;
 
ret = mutex_lock_interruptible(>struct_mutex);
@@ -2009,10 +2001,6 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
return ret;
 
list_for_each_entry(ctx, _priv->context_list, link) {
-   if (!i915.enable_execlists &&
-   ctx->legacy_hw_ctx.rcs_state == NULL)
-   continue;
-
seq_printf(m, "HW context %u ", ctx->hw_id);
if (IS_ERR(ctx->file_priv)) {
seq_puts(m, "(deleted) ");
@@ -2029,25 +2017,18 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
} else
seq_puts(m, "(kernel) ");
 
-   describe_ctx(m, ctx);
+   seq_putc(m, ctx->remap_slice ? 'R' : 'r');
+   seq_putc(m, '\n');
 
-   if (i915.enable_execlists) {
+   for_each_engine(engine, dev_priv) {
+   struct intel_context *ce = >engine[engine->id];
+   seq_printf(m, "%s: ", engine->name);
+   seq_putc(m, ce->initialised ? 'I' : 'i');
+   if (ce->state)
+   describe_obj(m, ce->state);
+   if (ce->ringbuf)
+   describe_ctx_ringbuf(m, ce->ringbuf);
seq_putc(m, '\n');
-   for_each_engine_id(engine, dev_priv, id) {
-   struct drm_i915_gem_object *ctx_obj =
-   ctx->engine[id].state;
-   struct intel_ringbuffer *ringbuf =
-   ctx->engine[id].ringbuf;
-
-   seq_printf(m, "%s: ", engine->name);
-   if (ctx_obj)
-   describe_obj(m, ctx_obj);
-   if (ringbuf)
-   describe_ctx_ringbuf(m, ringbuf);
-   seq_putc(m, '\n');
-   }
-   } else {
-   describe_obj(m, ctx->legacy_hw_ctx.rcs_state);
}
 
seq_putc(m, '\n');
@@ -2062,10 +2043,10 @@ static void i915_dump_lrc_obj(struct seq_file *m,
  struct i915_gem_context *ctx,
  struct intel_engine_cs *engine)
 {
+   struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
struct page *page;
uint32_t *reg_state;
int j;
-   struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
unsigned long ggtt_offset = 0;
 
seq_printf(m, "CONTEXT: %s %u\n", engine->name, ctx->hw_id);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b2428bceadd9..5832082d6e8f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -862,13 +862,6 @@ struct i915_gem_context {
/* Unique identifier 

[Intel-gfx] [CI 05/10] drm/i915: Move pinning of dev_priv->kernel_context into its creator

[Chris Wilson]

Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.

v2: Throw away the user_handle on failure to allocate the ppgtt.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 53 +++--
 1 file changed, 24 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index a3f9adb22a73..104d4819aca8 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -303,9 +303,7 @@ static struct i915_gem_context *
 i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
 {
-   const bool is_global_default_ctx = file_priv == NULL;
struct i915_gem_context *ctx;
-   int ret = 0;
 
lockdep_assert_held(>struct_mutex);
 
@@ -313,30 +311,15 @@ i915_gem_create_context(struct drm_device *dev,
if (IS_ERR(ctx))
return ctx;
 
-   if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
-   /* We may need to do things with the shrinker which
-* require us to immediately switch back to the default
-* context. This can cause a problem as pinning the
-* default context also requires GTT space which may not
-* be available. To avoid this we always pin the default
-* context.
-*/
-   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
-   
get_context_alignment(to_i915(dev)), 0);
-   if (ret) {
-   DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
-   goto err_destroy;
-   }
-   }
-
if (USES_FULL_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
 
-   if (IS_ERR_OR_NULL(ppgtt)) {
+   if (IS_ERR(ppgtt)) {
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
 PTR_ERR(ppgtt));
-   ret = PTR_ERR(ppgtt);
-   goto err_unpin;
+   idr_remove(_priv->context_idr, ctx->user_handle);
+   i915_gem_context_unreference(ctx);
+   return ERR_CAST(ppgtt);
}
 
ctx->ppgtt = ppgtt;
@@ -345,14 +328,6 @@ i915_gem_create_context(struct drm_device *dev,
trace_i915_context_create(ctx);
 
return ctx;
-
-err_unpin:
-   if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
-   i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
-err_destroy:
-   idr_remove(_priv->context_idr, ctx->user_handle);
-   i915_gem_context_unreference(ctx);
-   return ERR_PTR(ret);
 }
 
 static void i915_gem_context_unpin(struct i915_gem_context *ctx,
@@ -426,6 +401,26 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
 
+   if (ctx->legacy_hw_ctx.rcs_state) {
+   int ret;
+
+   /* We may need to do things with the shrinker which
+* require us to immediately switch back to the default
+* context. This can cause a problem as pinning the
+* default context also requires GTT space which may not
+* be available. To avoid this we always pin the default
+* context.
+*/
+   ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state,
+   get_context_alignment(dev_priv), 0);
+   if (ret) {
+   DRM_ERROR("Failed to pinned default global context 
(error %d)\n",
+ ret);
+   i915_gem_context_unreference(ctx);
+   return ret;
+   }
+   }
+
dev_priv->kernel_context = ctx;
 
DRM_DEBUG_DRIVER("%s context support initialized\n",
-- 
2.8.1

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

[Intel-gfx] [CI 10/10] drm/i915/debugfs: Show context objects in i915_gem_objects

[Chris Wilson]

One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
can compare the number of allocated objects and who owns them, a
discrepancy here often indicates a kernel bug. One allocator of unreported
objects is for backing context objects, so include those in the listing.

v2: Take filelist_mutex which requires a little dance with struct_mutex
to avoid nesting filelist_mutex inside struct_mutex.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 38 -
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 95a871b8f379..17e2b1a1c4ad 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,42 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
 }
 
+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+   struct i915_gem_context *ctx = ptr;
+   int n;
+
+   for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+   if (ctx->engine[n].state)
+   per_file_stats(0, ctx->engine[n].state, data);
+   if (ctx->engine[n].ringbuf)
+   per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+   }
+
+   return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+   struct drm_i915_private *dev_priv)
+{
+   struct file_stats stats;
+   struct drm_file *file;
+
+   memset(, 0, sizeof(stats));
+
+   mutex_lock(_priv->dev->struct_mutex);
+   if (dev_priv->kernel_context)
+   per_file_ctx_stats(0, dev_priv->kernel_context, );
+
+   list_for_each_entry(file, _priv->dev->filelist, lhead) {
+   struct drm_i915_file_private *fpriv = file->driver_priv;
+   idr_for_each(>context_idr, per_file_ctx_stats, );
+   }
+   mutex_unlock(_priv->dev->struct_mutex);
+
+   print_file_stats(m, "[k]contexts", stats);
+}
+
 #define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,10 +557,10 @@ static int i915_gem_object_info(struct seq_file *m, void* 
data)
 
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
-
mutex_unlock(>struct_mutex);
 
mutex_lock(>filelist_mutex);
+   print_context_stats(m, dev_priv);
list_for_each_entry_reverse(file, >filelist, lhead) {
struct file_stats stats;
struct task_struct *task;
-- 
2.8.1

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

[Intel-gfx] [CI 02/10] drm/i915: Apply lockdep annotations to i915_gem_context.c

[Chris Wilson]

Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep annotations are invaluable.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 18 +++---
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 961ef403154e..820748d65939 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3439,6 +3439,7 @@ static inline void i915_gem_context_reference(struct 
i915_gem_context *ctx)
 
 static inline void i915_gem_context_unreference(struct i915_gem_context *ctx)
 {
+   lockdep_assert_held(>i915->dev->struct_mutex);
kref_put(>ref, i915_gem_context_free);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8484da26b5d4..6b4c5adf4b89 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
 {
struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
 
+   lockdep_assert_held(>i915->dev->struct_mutex);
trace_i915_context_free(ctx);
 
if (i915.enable_execlists)
@@ -181,6 +182,8 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t 
size)
struct drm_i915_gem_object *obj;
int ret;
 
+   lockdep_assert_held(>struct_mutex);
+
obj = i915_gem_object_create(dev, size);
if (IS_ERR(obj))
return obj;
@@ -304,7 +307,7 @@ i915_gem_create_context(struct drm_device *dev,
struct i915_gem_context *ctx;
int ret = 0;
 
-   BUG_ON(!mutex_is_locked(>struct_mutex));
+   lockdep_assert_held(>struct_mutex);
 
ctx = __create_hw_context(dev, file_priv);
if (IS_ERR(ctx))
@@ -368,6 +371,8 @@ void i915_gem_context_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   lockdep_assert_held(>struct_mutex);
+
if (i915.enable_execlists) {
struct i915_gem_context *ctx;
 
@@ -433,6 +438,8 @@ void i915_gem_context_lost(struct drm_i915_private 
*dev_priv)
 {
struct intel_engine_cs *engine;
 
+   lockdep_assert_held(_priv->dev->struct_mutex);
+
for_each_engine(engine, dev_priv) {
if (engine->last_context == NULL)
continue;
@@ -451,6 +458,8 @@ void i915_gem_context_fini(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct i915_gem_context *dctx = dev_priv->kernel_context;
 
+   lockdep_assert_held(>struct_mutex);
+
if (dctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
 
@@ -491,6 +500,8 @@ void i915_gem_context_close(struct drm_device *dev, struct 
drm_file *file)
 {
struct drm_i915_file_private *file_priv = file->driver_priv;
 
+   lockdep_assert_held(>struct_mutex);
+
idr_for_each(_priv->context_idr, context_idr_cleanup, NULL);
idr_destroy(_priv->context_idr);
 }
@@ -500,6 +511,8 @@ i915_gem_context_get(struct drm_i915_file_private 
*file_priv, u32 id)
 {
struct i915_gem_context *ctx;
 
+   lockdep_assert_held(_priv->dev_priv->dev->struct_mutex);
+
ctx = idr_find(_priv->context_idr, id);
if (!ctx)
return ERR_PTR(-ENOENT);
@@ -852,10 +865,9 @@ unpin_out:
 int i915_switch_context(struct drm_i915_gem_request *req)
 {
struct intel_engine_cs *engine = req->engine;
-   struct drm_i915_private *dev_priv = req->i915;
 
WARN_ON(i915.enable_execlists);
-   WARN_ON(!mutex_is_locked(_priv->dev->struct_mutex));
+   lockdep_assert_held(>i915->dev->struct_mutex);
 
if (engine->id != RCS ||
req->ctx->legacy_hw_ctx.rcs_state == NULL) {
-- 
2.8.1

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

[Intel-gfx] [CI 07/10] drm/i915: Put the kernel_context in drm_i915_private next to its friends

[Chris Wilson]

Just move the kernel_context member of drm_i915_private next to the
engines it is associated with.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h| 3 +--
 drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 784978d33758..b2428bceadd9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1760,6 +1760,7 @@ struct drm_i915_private {
wait_queue_head_t gmbus_wait_queue;
 
struct pci_dev *bridge_dev;
+   struct i915_gem_context *kernel_context;
struct intel_engine_cs engine[I915_NUM_ENGINES];
struct drm_i915_gem_object *semaphore_obj;
uint32_t last_seqno, next_seqno;
@@ -2017,8 +2018,6 @@ struct drm_i915_private {
void (*stop_engine)(struct intel_engine_cs *engine);
} gt;
 
-   struct i915_gem_context *kernel_context;
-
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 7b3c96e6ea37..ac72451c571c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -935,11 +935,12 @@ int i915_guc_submission_enable(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = _priv->guc;
-   struct i915_gem_context *ctx = dev_priv->kernel_context;
struct i915_guc_client *client;
 
/* client for execbuf submission */
-   client = guc_client_alloc(dev, GUC_CTX_PRIORITY_KMD_NORMAL, ctx);
+   client = guc_client_alloc(dev,
+ GUC_CTX_PRIORITY_KMD_NORMAL,
+ dev_priv->kernel_context);
if (!client) {
DRM_ERROR("Failed to create execbuf guc_client\n");
return -ENOMEM;
-- 
2.8.1

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

[Intel-gfx] [CI 03/10] drm/i915: Rename and inline i915_gem_context_get()

[Chris Wilson]

i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h| 17 +++--
 drivers/gpu/drm/i915/i915_gem_context.c| 22 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 820748d65939..e0c932054cd8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3427,11 +3427,24 @@ void i915_gem_context_reset(struct drm_device *dev);
 int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
 void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
 int i915_switch_context(struct drm_i915_gem_request *req);
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
 void i915_gem_context_free(struct kref *ctx_ref);
 struct drm_i915_gem_object *
 i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
+
+static inline struct i915_gem_context *
+i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
+{
+   struct i915_gem_context *ctx;
+
+   lockdep_assert_held(_priv->dev_priv->dev->struct_mutex);
+
+   ctx = idr_find(_priv->context_idr, id);
+   if (!ctx)
+   return ERR_PTR(-ENOENT);
+
+   return ctx;
+}
+
 static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
 {
kref_get(>ref);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6b4c5adf4b89..a3f9adb22a73 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -506,20 +506,6 @@ void i915_gem_context_close(struct drm_device *dev, struct 
drm_file *file)
idr_destroy(_priv->context_idr);
 }
 
-struct i915_gem_context *
-i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
-{
-   struct i915_gem_context *ctx;
-
-   lockdep_assert_held(_priv->dev_priv->dev->struct_mutex);
-
-   ctx = idr_find(_priv->context_idr, id);
-   if (!ctx)
-   return ERR_PTR(-ENOENT);
-
-   return ctx;
-}
-
 static inline int
 mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
 {
@@ -951,7 +937,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, 
void *data,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
@@ -977,7 +963,7 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, 
void *data,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
@@ -1020,7 +1006,7 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
@@ -1072,7 +1058,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev,
if (ret)
return ret;
 
-   ctx = i915_gem_context_get(file->driver_priv, args->ctx_id);
+   ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
if (IS_ERR(ctx)) {
mutex_unlock(>struct_mutex);
return PTR_ERR(ctx);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e61b92d7b0bc..84d990331abd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1075,7 +1075,7 @@ i915_gem_validate_context(struct drm_device *dev, struct 
drm_file *file,
if (engine->id != RCS && ctx_id != DEFAULT_CONTEXT_HANDLE)
return ERR_PTR(-EINVAL);
 
-   ctx = i915_gem_context_get(file->driver_priv, ctx_id);
+   ctx = i915_gem_context_lookup(file->driver_priv, ctx_id);
if (IS_ERR(ctx))
return ctx;
 
-- 
2.8.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [CI 06/10] drm/i915: Show i915_gem_context owner in debugfs

[Chris Wilson]

Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).

v2: Mark the file_priv as closed.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
 drivers/gpu/drm/i915/i915_gem_context.c |  3 ++-
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 424e11efa3e1..e81b795005b9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2014,9 +2014,22 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
continue;
 
seq_printf(m, "HW context %u ", ctx->hw_id);
+   if (IS_ERR(ctx->file_priv)) {
+   seq_puts(m, "(deleted) ");
+   } else if (ctx->file_priv) {
+   struct pid *pid = ctx->file_priv->file->pid;
+   struct task_struct *task;
+
+   task = get_pid_task(pid, PIDTYPE_PID);
+   if (task) {
+   seq_printf(m, "(%s [%d]) ",
+  task->comm, task->pid);
+   put_task_struct(task);
+   }
+   } else
+   seq_puts(m, "(kernel) ");
+
describe_ctx(m, ctx);
-   if (ctx == dev_priv->kernel_context)
-   seq_printf(m, "(kernel context) ");
 
if (i915.enable_execlists) {
seq_putc(m, '\n');
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 104d4819aca8..8d8c79b88816 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -468,6 +468,7 @@ static int context_idr_cleanup(int id, void *p, void *data)
 {
struct i915_gem_context *ctx = p;
 
+   ctx->file_priv = ERR_PTR(-EBADF);
i915_gem_context_unreference(ctx);
return 0;
 }
@@ -938,7 +939,7 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev, 
void *data,
return PTR_ERR(ctx);
}
 
-   idr_remove(>file_priv->context_idr, ctx->user_handle);
+   idr_remove(_priv->context_idr, ctx->user_handle);
i915_gem_context_unreference(ctx);
mutex_unlock(>struct_mutex);
 
-- 
2.8.1

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

[Intel-gfx] [CI 09/10] drm/i915: Rearrange i915_gem_context

[Chris Wilson]

Pack the integers and related types together inside the struct.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5832082d6e8f..490f0d821d2b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -829,7 +829,6 @@ struct i915_ctx_hang_stats {
 /* This must match up with the value previously used for execbuf2.rsvd1. */
 #define DEFAULT_CONTEXT_HANDLE 0
 
-#define CONTEXT_NO_ZEROMAP (1<<0)
 /**
  * struct i915_gem_context - as the name implies, represents a context.
  * @ref: reference count.
@@ -851,28 +850,31 @@ struct i915_ctx_hang_stats {
  */
 struct i915_gem_context {
struct kref ref;
-   int user_handle;
-   uint8_t remap_slice;
struct drm_i915_private *i915;
-   int flags;
struct drm_i915_file_private *file_priv;
-   struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
 
+   struct i915_ctx_hang_stats hang_stats;
+
/* Unique identifier for this context, used by the hw for tracking */
unsigned hw_id;
+   uint32_t user_handle;
+   unsigned long flags;
+#define CONTEXT_NO_ZEROMAP (1<<0)
 
struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
-   int pin_count;
struct i915_vma *lrc_vma;
-   u64 lrc_desc;
uint32_t *lrc_reg_state;
+   u64 lrc_desc;
+   int pin_count;
bool initialised;
} engine[I915_NUM_ENGINES];
 
struct list_head link;
+
+   uint8_t remap_slice;
 };
 
 enum fb_op_origin {
-- 
2.8.1

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

[Intel-gfx] [CI 01/10] drm/i915: Rename struct intel_context

[Chris Wilson]

Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target different users. The outer
struct is API / user facing, and so carries the higher level GEM
information. The inner struct is hw facing. Thus we want to name the
inner struct intel_context and the outer one i915_gem_context. As the
first step, we need to rename the current struct:

s/struct intel_context/struct i915_gem_context/

which fits much better with its constructors already conveying the
i915_gem_context prefix!

Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 10 +++---
 drivers/gpu/drm/i915/i915_drv.h| 22 ++---
 drivers/gpu/drm/i915/i915_gem.c|  8 ++---
 drivers/gpu/drm/i915/i915_gem_context.c| 52 +++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +++---
 drivers/gpu/drm/i915/i915_guc_submission.c | 12 +++
 drivers/gpu/drm/i915/i915_sysfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_trace.h  | 12 +++
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 22 ++---
 drivers/gpu/drm/i915/intel_lrc.h   | 10 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  4 +--
 12 files changed, 84 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e606c6acef0f..424e11efa3e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -199,7 +199,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
 }
 
-static void describe_ctx(struct seq_file *m, struct intel_context *ctx)
+static void describe_ctx(struct seq_file *m, struct i915_gem_context *ctx)
 {
seq_putc(m, ctx->legacy_hw_ctx.initialized ? 'I' : 'i');
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
@@ -2000,7 +2000,7 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
-   struct intel_context *ctx;
+   struct i915_gem_context *ctx;
enum intel_engine_id id;
int ret;
 
@@ -2046,7 +2046,7 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
 }
 
 static void i915_dump_lrc_obj(struct seq_file *m,
- struct intel_context *ctx,
+ struct i915_gem_context *ctx,
  struct intel_engine_cs *engine)
 {
struct page *page;
@@ -2094,7 +2094,7 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
-   struct intel_context *ctx;
+   struct i915_gem_context *ctx;
int ret;
 
if (!i915.enable_execlists) {
@@ -2274,7 +2274,7 @@ static int i915_swizzle_info(struct seq_file *m, void 
*data)
 
 static int per_file_ctx(int id, void *ptr, void *data)
 {
-   struct intel_context *ctx = ptr;
+   struct i915_gem_context *ctx = ptr;
struct seq_file *m = data;
struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 78d38c246491..961ef403154e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -831,7 +831,7 @@ struct i915_ctx_hang_stats {
 
 #define CONTEXT_NO_ZEROMAP (1<<0)
 /**
- * struct intel_context - as the name implies, represents a context.
+ * struct i915_gem_context - as the name implies, represents a context.
  * @ref: reference count.
  * @user_handle: userspace tracking identity for this context.
  * @remap_slice: l3 row remapping information.
@@ -849,7 +849,7 @@ struct i915_ctx_hang_stats {
  * Contexts are memory images used by the hardware to store copies of their
  * internal state.
  */
-struct intel_context {
+struct i915_gem_context {
struct kref ref;
int user_handle;
uint8_t remap_slice;
@@ -1710,7 +1710,7 @@ struct i915_execbuffer_params {
uint64_tbatch_obj_vm_offset;
struct intel_engine_cs *engine;
struct drm_i915_gem_object  *batch_obj;
-   struct intel_context*ctx;
+   struct i915_gem_context*ctx;
struct drm_i915_gem_request *request;
 };
 
@@ -2017,7 +2017,7 @@ struct drm_i915_private {
void (*stop_engine)(struct 

[Intel-gfx] [CI 04/10] drm/i915: Name the inner most per-engine intel_context struct

[Chris Wilson]

We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (the logical context
state, the registers, the ringbuffer etc).

Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
Cc: Tvrtko Ursulin 
Reviewed-by Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++---
 drivers/gpu/drm/i915/intel_lrc.c   | 90 +++---
 3 files changed, 51 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0c932054cd8..784978d33758 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -869,7 +869,7 @@ struct i915_gem_context {
} legacy_hw_ctx;
 
/* Execlists */
-   struct {
+   struct intel_context {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
int pin_count;
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b42a3adc3fa4..7b3c96e6ea37 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -363,7 +363,6 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_gem_context *ctx = client->owner;
struct guc_context_desc desc;
struct sg_table *sg;
-   enum intel_engine_id id;
u32 gfx_addr;
 
memset(, 0, sizeof(desc));
@@ -373,10 +372,10 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
 
-   for_each_engine_id(engine, dev_priv, id) {
+   for_each_engine(engine, dev_priv) {
+   struct intel_context *ce = >engine[engine->id];
struct guc_execlist_context *lrc = [engine->guc_id];
struct drm_i915_gem_object *obj;
-   uint64_t ctx_desc;
 
/* 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
@@ -385,20 +384,18 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 * for now who owns a GuC client. But for future owner of GuC
 * client, need to make sure lrc is pinned prior to enter here.
 */
-   obj = ctx->engine[id].state;
-   if (!obj)
+   if (!ce->state)
break;  /* XXX: continue? */
 
-   ctx_desc = intel_lr_context_descriptor(ctx, engine);
-   lrc->context_desc = (u32)ctx_desc;
+   lrc->context_desc = lower_32_bits(ce->lrc_desc);
 
/* The state page is after PPHWSP */
-   gfx_addr = i915_gem_obj_ggtt_offset(obj);
+   gfx_addr = i915_gem_obj_ggtt_offset(ce->state);
lrc->ring_lcra = gfx_addr + LRC_STATE_PN * PAGE_SIZE;
lrc->context_id = (client->ctx_index << GUC_ELC_CTXID_OFFSET) |
(engine->guc_id << GUC_ELC_ENGINE_OFFSET);
 
-   obj = ctx->engine[id].ringbuf->obj;
+   obj = ce->ringbuf->obj;
gfx_addr = i915_gem_obj_ggtt_offset(obj);
 
lrc->ring_begin = gfx_addr;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3d95b26b32ef..a1dba678942d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -300,7 +300,7 @@ logical_ring_init_platform_invariants(struct 
intel_engine_cs *engine)
  *   descriptor for a pinned context
  *
  * @ctx: Context to work on
- * @ring: Engine the descriptor will be used with
+ * @engine: Engine the descriptor will be used with
  *
  * The context descriptor encodes various attributes of a context,
  * including its GTT address and some flags. Because it's fairly
@@ -318,16 +318,17 @@ static void
 intel_lr_context_descriptor_update(struct i915_gem_context *ctx,
   struct intel_engine_cs *engine)
 {
+   struct intel_context *ce = >engine[engine->id];
u64 desc;
 
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1<ctx_desc_template;   /* bits  0-11 */
-   desc |= ctx->engine[engine->id].lrc_vma->node.start +   /* bits 12-31 */
-  LRC_PPHWSP_PN * PAGE_SIZE;
+   desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
+   /* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT;   /* bits 32-52 */
 
-   

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix warnings from atomic nonblocking unpin.

[Maarten Lankhorst]

Op 24-05-16 om 13:52 schreef Patchwork:
> == Series Details ==
>
> Series: drm/i915: Fix warnings from atomic nonblocking unpin.
> URL   : https://patchwork.freedesktop.org/series/7629/
> State : failure
>
> == Summary ==
>
> Series 7629v1 drm/i915: Fix warnings from atomic nonblocking unpin.
> http://patchwork.freedesktop.org/api/1.0/series/7629/revisions/1/mbox
>
> Test gem_basic:
> Subgroup create-close:
> pass   -> DMESG-WARN (ro-skl-i7-6700hq)

[  203.104683] [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic 
update failure on pipe A

> Test gem_ringfill:
> Subgroup basic-default-hang:
> pass   -> DMESG-WARN (ro-skl-i7-6700hq)

[  356.602203] [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic 
update failure on pipe A

> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b-frame-sequence:
> pass   -> FAIL   (ro-byt-n2820)
Not sure why this suddenly fails, previous patch series never showed this 
problem, only difference is related to legacy cursor updates
and lower max pin count. Neither is the case here..
> Test kms_psr_sink_crc:
> Subgroup psr_basic:
> pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Random atomic update failure again.
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> fail   -> DMESG-WARN (ro-skl-i7-6700hq)
host2guc error..
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v5 0/7] kms_flip_event_leak and kms_vblank fixes for

[Robert Foss]

Hey,

Thanks for being thorough, give me a shout if there is anything specific 
I can help you look into.



Rob.

On 2016-05-24 07:19 AM, Marius Vlad wrote:

Hi,

I'm getting mixed results w/ this series applied. The kernel seems to
trip in different ways either from suspend or on reload (running the BAT
suite on a HSW machine), and though it seems totally
unrelated I can't reproduce the same behaviour without the series
applied. Haven't managed to get some valid output as the machine
dead-locks/freezes, so please be patient until I try to isolate the
problem. It could be I stumbled something totally unrelated.


On Mon, May 16, 2016 at 09:38:25AM -0400, robert.f...@collabora.com wrote:

From: Robert Foss 

In addition to the changes made in v4, danvet suggested that the argument for
the (newly renamed) helper function kmstest_get_vbl_flag should be changed.

I investigated it and found that all of the places where the helper function
currently is used, would require more of a rework with changed arguments than
with unchanged arguments, so I decided to not change the arguments.

Changes since v1:
- kms_vblank: Removed un-used members of data_t struct.
- Rename plane_counter to n_planes.
- Removed un-needed handling CURSOR plane location.
- Added names for additional planes in update kmstest_plane_name.

Changes since v2:
- Rebased onto trunk which already contains kms_flip_event_leak changes.

Changes since v3:
- kms_vblank.c: Removed drm_fd from data_t, to decrease the number of
unrelated changes in the patch.
- kms_vblank.c: Changed "int valid_tests" to "unsigned valid_tests".
- kms_vblank.c: Changed crtc_id_flag/crtc_id_to_flag to
pipe_id_flag/pipe_id_to_flag.
- kms_vblank.c: Changed to "vbl.request.type |= crtc_id_flag;".
- kms_vblank.c: Moved crtc_id_to_flag to igt_kms.c.
- kms_vblank.c: Renamed crtc_id_to_flag to pipe_id_to_vbl_flag.
- kms_flip.c: Changed test busy_mode boolean into mode_busy bitfield in struct
data.
- igt_kms.h: Moved IGT_PLANE_CURSOR position comment.

Changes since v4:
- kms_vblank.c: Removed whitespace at end of file.
- igt_kms: Changed name of helper function to kmstest_get_vbl_flag
- igt_kms: Changed kmstest_get_vbl_flag to not set DRM_VBLANK_RELATIVE flag

Robert Foss (7):
   lib/igt_kms: Add support for up to 10 planes.
   lib/igt_kms: Fix plane counting in igt_display_init.
   lib/igt_kms: Switch to verbose assert.
   lib/igt_kms: Added pipe_id_to_vbl_flag() to igt_kms.
   kms_vblank: Switch from using crtc0 statically to explicitly setting
 mode.
   igt_kms: Change igt_wait_for_vblank to use helper function.
   kms_flip: Change __wait_for_vblank to use helper function.

  lib/igt_kms.c  |  36 ++--
  lib/igt_kms.h  |   9 ++-
  tests/kms_flip.c   |   8 +--
  tests/kms_vblank.c | 161 -
  4 files changed, 179 insertions(+), 35 deletions(-)

--
2.7.4


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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v2,1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Imre Deak]

On ti, 2016-05-24 at 13:02 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,1/2] drm/i915/gen9: Assume CDCLK PLL
> is off if it's not locked
> URL   : https://patchwork.freedesktop.org/series/7631/
> State : failure
> 
> == Summary ==
> 
> Series 7631v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/7631/revisions/1/mbox
> 
> Test gem_busy:
> Subgroup basic-parallel-vebox:
> dmesg-warn -> PASS   (ro-skl-i7-6700hq)
> Test gem_exec_basic:
> Subgroup readonly-vebox:
> pass   -> DMESG-WARN (ro-skl-i7-6700hq)

[drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on 
pipe A

https://bugs.freedesktop.org/show_bug.cgi?id=95632

> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> pass   -> FAIL   (ro-byt-n2820)

Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [gem_execbuf+0x44]
  #2 [batch+0x4bd]
  #3 [__real_main481+0x308]
  #4 [main+0x23]
  #5 [__libc_start_main+0xf0]
  #6 [_start+0x29]
  #7 [+0x29]
child 0 failed with exit status 99

(gem_exec_flush:6087) ioctl-wrappers-CRITICAL: Failed assertion: 
__gem_execbuf(fd, execbuf) == 0
(gem_exec_flush:6087) ioctl-wrappers-CRITICAL: error: -22 != 0
Subtest basic-batch-kernel-default-cmd failed.

https://bugs.freedesktop.org/show_bug.cgi?id=95372

> Test gem_exec_store:
> Subgroup basic-bsd:
> pass   -> DMESG-WARN (ro-skl-i7-6700hq)
> Test gem_ringfill:
> Subgroup basic-default-interruptible:
> dmesg-warn -> PASS   (ro-skl-i7-6700hq)
> Test gem_storedw_loop:
> Subgroup basic-default:
> dmesg-warn -> PASS   (ro-skl-i7-6700hq)
> Test kms_pipe_crc_basic:
> Subgroup bad-pipe:
> dmesg-warn -> PASS   (ro-skl-i7-6700hq)
> Test kms_psr_sink_crc:
> Subgroup psr_basic:
> pass   -> DMESG-WARN (ro-skl-i7-6700hq)
> Test kms_setmode:
> Subgroup basic-clone-single-crtc:
> pass   -> DMESG-WARN (ro-skl-i7-6700hq)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> fail   -> DMESG-WARN (ro-skl-i7-6700hq)

All the remaining WARNs are the above "Potential atomic update failure"
 error message, so assuming the same bug as above.

> 
> ro-bdw-i5-
> 5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
> ro-bdw-i7-
> 5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
> ro-bdw-i7-
> 5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
> ro-byt-
> n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
> ro-hsw-i3-
> 4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
> ro-hsw-i7-
> 4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
> ro-ilk-i7-
> 620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
> ro-ilk1-i5-
> 650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
> ro-ivb-i7-
> 3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
> ro-ivb2-i7-
> 3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
> ro-skl-i7-6700hq
> total:204  pass:175  dwarn:8   dfail:0   fail:0   skip:21 
> ro-snb-i7-
> 2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_993/
> 
> 8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration
> manifest
> a416d47 drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume
> c1d96b1 drm/i915/gen9: Assume CDCLK PLL is off if it's not locked
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/ilk: Don't disable SSC source if it's in use

[Ville Syrjälä]

On Mon, May 23, 2016 at 03:56:36PM -0400, Lyude wrote:
> Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
> 
> Unfortunately one of the sideaffects of having the refclk for a DPLL set
> to SSC is that as long as it's set to SSC, the GPU will prevent us from
> powering down any of the pipes or transcoders using it. A couple of
> BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
> configurations. This causes issues on the first modeset, since we don't
> expect SSC to be left on and as a result, can't successfully power down
> the pipes or the transcoders using it. Here's an example from this Dell
> OptiPlex 990:
> 
> [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says 
> disabled
> [drm:intel_modeset_init] 2 display pipes available.
> [drm:intel_update_cdclk] Current CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max CD clock rate: 40 kHz
> [drm:intel_update_max_cdclk] Max dotclock rate: 36 kHz
> vgaarb: device changed decodes: 
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [drm:intel_crt_reset] crt adpa set to 0xf4
> [drm:intel_dp_init_connector] Adding DP connector on port C
> [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
> [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
> [drm:ironlake_init_pch_refclk] Disabling SSC entirely
> … later we try committing the first modeset …
> [drm:intel_dump_pipe_config] [CRTC:26][modeset] config 88041b02e800 for 
> pipe A
> [drm:intel_dump_pipe_config] cpu_transcoder: A
> …
> [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, 
> fp0: 0x20e08, fp1: 0x30d07
> [drm:intel_dump_pipe_config] planes on this crtc
> [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
> [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258
> [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 
> 800x600
> [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, 
> scaler_id = 0
> [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, 
> scaler_id = 0
> [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
> [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
> [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
> [drm:intel_disable_pipe] disabling pipe A
> [ cut here ]
> WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 
> intel_disable_pipe+0x297/0x2d0 [i915]
> pipe_off wait timed out
> …
> ---[ end trace 94fc8aa03ae139e8 ]---
> [drm:intel_dp_link_down]
> [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
> 
> Later modesets succeed since they reset the DPLL's configuration anyway,
> but this is enough to get stuck with a big fat warning in dmesg.
> 
> A better solution would be to add refcounts for the SSC source, but for
> now leaving the source clock on should suffice.
> 
> Changes since v1:
>  - Leave the SSC source clock on instead of just shutting it off on all
>of the DPLL configurations.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude 
> ---
> Sorry about that! I misread danvet's suggestion as "disable the SSC" instead 
> of
> "don't disable the SSC".
> 
>  drivers/gpu/drm/i915/intel_display.c | 47 
> +++-
>  1 file changed, 35 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d500e6f..dff8511 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8230,12 +8230,14 @@ static void ironlake_init_pch_refclk(struct 
> drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_encoder *encoder;
> - u32 val, final;
> + int i;
> + u32 val, temp, final;
>   bool has_lvds = false;
>   bool has_cpu_edp = false;
>   bool has_panel = false;
>   bool has_ck505 = false;
>   bool can_ssc = false;
> + bool using_ssc_source = false;
>  
>   /* We need to take the global config into account */
>   for_each_intel_encoder(dev, encoder) {
> @@ -8283,9 +8285,26 @@ static void ironlake_init_pch_refclk(struct drm_device 
> *dev)
>   else
>   final |= DREF_NONSPREAD_SOURCE_ENABLE;
>  
> - final &= ~DREF_SSC_SOURCE_MASK;
>   final &= ~DREF_CPU_SOURCE_OUTPUT_MASK;
> - final &= ~DREF_SSC1_ENABLE;
> +
> + /* Check if any DPLLs are using the SSC source */
> + for (i = 0; i < dev_priv->num_shared_dpll; i++) {
> + temp = I915_READ(PCH_DPLL(i));
> +
> + if (!(temp & DPLL_VCO_ENABLE))
> + continue;
> +
> + if ((temp & PLL_REF_INPUT_MASK) ==
> + PLLB_REF_INPUT_SPREADSPECTRUMIN) {
> + using_ssc_source = true;
> + break;
> + }
> + }
> +
> + if 

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v2,1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/gen9: Assume CDCLK PLL is off if 
it's not locked
URL   : https://patchwork.freedesktop.org/series/7631/
State : failure

== Summary ==

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

Test gem_busy:
Subgroup basic-parallel-vebox:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_exec_basic:
Subgroup readonly-vebox:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)
Test gem_exec_store:
Subgroup basic-bsd:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ringfill:
Subgroup basic-default-interruptible:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-WARN (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:175  dwarn:8   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_993/

8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration manifest
a416d47 drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume
c1d96b1 drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

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

[Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume

[Imre Deak]

I noticed that during S4 resume BIOS incorrectly sets bits 18, 19 which
are reserved/MBZ and sets the decimal frequency fields to all 0xff in
the CDCLK register. The result is a hard lockup as display register
accesses are attempted later. Work around this by sanitizing the CDCLK
PLL/dividers the same way it's done on SKL.

While this is clearly a BIOS bug which should be fixed separately, it
doesn't hurt to check/sanitize this regardless.

v2:
- Use the same condition for VCO and CDCLK in broxton_init_cdclk as is
  used in skl_init_cdclk for the same purpose.

CC: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c | 51 ++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 47b2466..19f947f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5412,11 +5412,58 @@ static void broxton_set_cdclk(struct drm_i915_private 
*dev_priv, int cdclk)
intel_update_cdclk(dev_priv->dev);
 }
 
+static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
+{
+   u32 cdctl, expected;
+
+   intel_update_cdclk(dev_priv->dev);
+
+   if (dev_priv->cdclk_pll.vco == 0 ||
+   dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
+   goto sanitize;
+
+   /* DPLL okay; verify the cdclock
+*
+* Some BIOS versions leave an incorrect decimal frequency value and
+* set reserved MBZ bits in CDCLK_CTL at least during exiting from S4,
+* so sanitize this register.
+*/
+   cdctl = I915_READ(CDCLK_CTL);
+   /*
+* Let's ignore the pipe field, since BIOS could have configured the
+* dividers both synching to an active pipe, or asynchronously
+* (PIPE_NONE).
+*/
+   cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
+
+   expected = (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) |
+  skl_cdclk_decimal(dev_priv->cdclk_freq);
+   /*
+* Disable SSA Precharge when CD clock frequency < 500 MHz,
+* enable otherwise.
+*/
+   if (dev_priv->cdclk_freq >= 50)
+   expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
+
+   if (cdctl == expected)
+   /* All well; nothing to sanitize */
+   return;
+
+sanitize:
+   DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
+
+   /* force cdclk programming */
+   dev_priv->cdclk_freq = 0;
+
+   /* force full PLL disable + enable */
+   dev_priv->cdclk_pll.vco = -1;
+}
+
 void broxton_init_cdclk(struct drm_i915_private *dev_priv)
 {
-   intel_update_cdclk(dev_priv->dev);
+   bxt_sanitize_cdclk(dev_priv);
 
-   if (dev_priv->cdclk_pll.vco != 0)
+   if (dev_priv->cdclk_freq != 0 && dev_priv->cdclk_pll.vco != 0)
return;
 
/*
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Imre Deak]

If the CDCLK PLL isn't locked or incorrectly configured we can just
assume that it's off resulting in fully re-initializing both CDCLK PLL
and CDCLK dividers. This way the CDCLK PLL sanitization added in the
following patch can be done on BXT the same way as it's done on SKL.

v2: (Ville)
- Remove the remaining PLL specific checks from skl_sanitize_cdclk() and
  depend instead on the corresponding check in skl_dpll0_update().
- Use vco == 0 instead of the corresponding boolean check in
  skl_sanitize_cdclk().

CC: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c | 39 +++-
 1 file changed, 16 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c1e666b..47b2466 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5461,21 +5461,22 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
u32 val;
 
dev_priv->cdclk_pll.ref = 24000;
+   dev_priv->cdclk_pll.vco = 0;
 
val = I915_READ(LCPLL1_CTL);
-   if ((val & LCPLL_PLL_ENABLE) == 0) {
-   dev_priv->cdclk_pll.vco = 0;
+   if ((val & LCPLL_PLL_ENABLE) == 0)
return;
-   }
 
-   WARN_ON((val & LCPLL_PLL_LOCK) == 0);
+   if (WARN_ON((val & LCPLL_PLL_LOCK) == 0))
+   return;
 
val = I915_READ(DPLL_CTRL1);
 
-   WARN_ON((val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
-   DPLL_CTRL1_SSC(SKL_DPLL0) |
-   DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
-   DPLL_CTRL1_OVERRIDE(SKL_DPLL0));
+   if (WARN_ON((val & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
+   DPLL_CTRL1_SSC(SKL_DPLL0) |
+   DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
+   DPLL_CTRL1_OVERRIDE(SKL_DPLL0)))
+   return;
 
switch (val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0)) {
case DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, SKL_DPLL0):
@@ -5490,7 +5491,6 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
break;
default:
MISSING_CASE(val & DPLL_CTRL1_LINK_RATE_MASK(SKL_DPLL0));
-   dev_priv->cdclk_pll.vco = 0;
break;
}
 }
@@ -5690,19 +5690,12 @@ static void skl_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
if ((I915_READ(SWF_ILK(0x18)) & 0x00FF) == 0)
goto sanitize;
 
+   intel_update_cdclk(dev_priv->dev);
/* Is PLL enabled and locked ? */
-   if ((I915_READ(LCPLL1_CTL) & (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK)) !=
-   (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK))
+   if (dev_priv->cdclk_pll.vco == 0 ||
+   dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
goto sanitize;
 
-   if ((I915_READ(DPLL_CTRL1) & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
- DPLL_CTRL1_SSC(SKL_DPLL0) |
- DPLL_CTRL1_OVERRIDE(SKL_DPLL0))) !=
-   DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
-   goto sanitize;
-
-   intel_update_cdclk(dev_priv->dev);
-
/* DPLL okay; verify the cdclock
 *
 * Noticed in some instances that the freq selection is correct but
@@ -6608,14 +6601,14 @@ static void bxt_de_pll_update(struct drm_i915_private 
*dev_priv)
u32 val;
 
dev_priv->cdclk_pll.ref = 19200;
+   dev_priv->cdclk_pll.vco = 0;
 
val = I915_READ(BXT_DE_PLL_ENABLE);
-   if ((val & BXT_DE_PLL_PLL_ENABLE) == 0) {
-   dev_priv->cdclk_pll.vco = 0;
+   if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
return;
-   }
 
-   WARN_ON((val & BXT_DE_PLL_LOCK) == 0);
+   if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
+   return;
 
val = I915_READ(BXT_DE_PLL_CTL);
dev_priv->cdclk_pll.vco = (val & BXT_DE_PLL_RATIO_MASK) *
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH] drm: use seqlock for vblank time/count

[Ville Syrjälä]

On Tue, May 10, 2016 at 03:21:28PM +0100, Matthew Auld wrote:
> This patch aims to replace the roll-your-own seqlock implementation with
> full-blown seqlock'. We also remove the timestamp ring-buffer in favour
> of single timestamp/count pair protected by a seqlock. In turn this
> means we can now increment the vblank freely without the need for
> clamping.
> 
> v2:
>   - reduce the scope of the seqlock, keeping vblank_time_lock
>   - make the seqlock per vblank_crtc, so multiple readers aren't blocked by
> the writer
> 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Signed-off-by: Matthew Auld 

LGTM

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_irq.c | 90 
> +++
>  include/drm/drmP.h| 14 +++-
>  2 files changed, 17 insertions(+), 87 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3c1a6f1..0e95100 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -42,10 +42,6 @@
>  #include 
>  #include 
>  
> -/* Access macro for slots in vblank timestamp ringbuffer. */
> -#define vblanktimestamp(dev, pipe, count) \
> - ((dev)->vblank[pipe].time[(count) % DRM_VBLANKTIME_RBSIZE])
> -
>  /* Retry timestamp calculation up to 3 times to satisfy
>   * drm_timestamp_precision before giving up.
>   */
> @@ -82,29 +78,15 @@ static void store_vblank(struct drm_device *dev, unsigned 
> int pipe,
>struct timeval *t_vblank, u32 last)
>  {
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
> - u32 tslot;
>  
>   assert_spin_locked(>vblank_time_lock);
>  
>   vblank->last = last;
>  
> - /* All writers hold the spinlock, but readers are serialized by
> -  * the latching of vblank->count below.
> -  */
> - tslot = vblank->count + vblank_count_inc;
> - vblanktimestamp(dev, pipe, tslot) = *t_vblank;
> -
> - /*
> -  * vblank timestamp updates are protected on the write side with
> -  * vblank_time_lock, but on the read side done locklessly using a
> -  * sequence-lock on the vblank counter. Ensure correct ordering using
> -  * memory barrriers. We need the barrier both before and also after the
> -  * counter update to synchronize with the next timestamp write.
> -  * The read-side barriers for this are in drm_vblank_count_and_time.
> -  */
> - smp_wmb();
> + write_seqlock(>seqlock);
> + vblank->time = *t_vblank;
>   vblank->count += vblank_count_inc;
> - smp_wmb();
> + write_sequnlock(>seqlock);
>  }
>  
>  /**
> @@ -205,7 +187,7 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   const struct timeval *t_old;
>   u64 diff_ns;
>  
> - t_old = (dev, pipe, vblank->count);
> + t_old = >time;
>   diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old);
>  
>   /*
> @@ -239,49 +221,6 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   diff = 1;
>   }
>  
> - /*
> -  * FIMXE: Need to replace this hack with proper seqlocks.
> -  *
> -  * Restrict the bump of the software vblank counter to a safe maximum
> -  * value of +1 whenever there is the possibility that concurrent readers
> -  * of vblank timestamps could be active at the moment, as the current
> -  * implementation of the timestamp caching and updating is not safe
> -  * against concurrent readers for calls to store_vblank() with a bump
> -  * of anything but +1. A bump != 1 would very likely return corrupted
> -  * timestamps to userspace, because the same slot in the cache could
> -  * be concurrently written by store_vblank() and read by one of those
> -  * readers without the read-retry logic detecting the collision.
> -  *
> -  * Concurrent readers can exist when we are called from the
> -  * drm_vblank_off() or drm_vblank_on() functions and other non-vblank-
> -  * irq callers. However, all those calls to us are happening with the
> -  * vbl_lock locked to prevent drm_vblank_get(), so the vblank refcount
> -  * can't increase while we are executing. Therefore a zero refcount at
> -  * this point is safe for arbitrary counter bumps if we are called
> -  * outside vblank irq, a non-zero count is not 100% safe. Unfortunately
> -  * we must also accept a refcount of 1, as whenever we are called from
> -  * drm_vblank_get() -> drm_vblank_enable() the refcount will be 1 and
> -  * we must let that one pass through in order to not lose vblank counts
> -  * during vblank irq off - which would completely defeat the whole
> -  * point of this routine.
> -  *
> -  * Whenever we are called from vblank irq, we have to assume concurrent
> -  * readers 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Ville Syrjälä]

On Tue, May 24, 2016 at 02:59:55PM +0300, Imre Deak wrote:
> On ti, 2016-05-24 at 13:22 +0300, Ville Syrjälä wrote:
> > On Tue, May 24, 2016 at 12:27:50PM +0300, Imre Deak wrote:
> > > If the CDCLK PLL isn't locked we can just assume that it's off resulting
> > > in fully re-initializing both CDCLK PLL and CDCLK dividers. This way the
> > > CDCLK PLL sanitization added in the following patch can be done on BXT
> > > the same way as it's done on SKL.
> > > 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 23 +++
> > >  1 file changed, 11 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index c1e666b..b8e5995 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -5461,14 +5461,14 @@ skl_dpll0_update(struct drm_i915_private 
> > > *dev_priv)
> > >   u32 val;
> > >  
> > >   dev_priv->cdclk_pll.ref = 24000;
> > > + dev_priv->cdclk_pll.vco = 0;
> > >  
> > >   val = I915_READ(LCPLL1_CTL);
> > > - if ((val & LCPLL_PLL_ENABLE) == 0) {
> > > - dev_priv->cdclk_pll.vco = 0;
> > > + if ((val & LCPLL_PLL_ENABLE) == 0)
> > >   return;
> > > - }
> > >  
> > > - WARN_ON((val & LCPLL_PLL_LOCK) == 0);
> > > + if (WARN_ON((val & LCPLL_PLL_LOCK) == 0))
> > > + return;
> > >  
> > >   val = I915_READ(DPLL_CTRL1);
> > >  
> > > @@ -5690,9 +5690,10 @@ static void skl_sanitize_cdclk(struct 
> > > drm_i915_private *dev_priv)
> > >   if ((I915_READ(SWF_ILK(0x18)) & 0x00FF) == 0)
> > >   goto sanitize;
> > >  
> > > + intel_update_cdclk(dev_priv->dev);
> > >   /* Is PLL enabled and locked ? */
> > > - if ((I915_READ(LCPLL1_CTL) & (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK)) !=
> > > - (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK))
> > > + if (!dev_priv->cdclk_pll.vco ||
> > 
> > == 0 please. I find that more pleasing to the eye when we end up mixing
> > with == anyway on the next line.
> 
> Ok.
> 
> > Actually is there any extra benefit from the cdclk_freq check? As
> > in would vco==0 be sufficient on its own?
> 
> The other check is for the case of an invalid CDCLK divider setting.
> Don't we care about that?

Oh right. I guess there's no harm in checking for it.

> 
> > > + dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
> > >   goto sanitize;
> > >  
> > >   if ((I915_READ(DPLL_CTRL1) & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
> > 
> > Maybe toss out this DPLL_CTRL1 check that I added as well then, and have
> > skl_dpll0_update() set the vco to 0 when it's crap. If we ever actually
> > hit this in the real world, we'll get the warn, and then we perhaps get
> > to rethink this stuff, but for now simpler seems better.
> 
> Ok, makes sense.
> 
> > > @@ -5701,8 +5702,6 @@ static void skl_sanitize_cdclk(struct 
> > > drm_i915_private *dev_priv)
> > >   DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
> > >   goto sanitize;
> > >  
> > > - intel_update_cdclk(dev_priv->dev);
> > > -
> > >   /* DPLL okay; verify the cdclock
> > >    *
> > >    * Noticed in some instances that the freq selection is correct but
> > > @@ -6608,14 +6607,14 @@ static void bxt_de_pll_update(struct 
> > > drm_i915_private *dev_priv)
> > >   u32 val;
> > >  
> > >   dev_priv->cdclk_pll.ref = 19200;
> > > + dev_priv->cdclk_pll.vco = 0;
> > >  
> > >   val = I915_READ(BXT_DE_PLL_ENABLE);
> > > - if ((val & BXT_DE_PLL_PLL_ENABLE) == 0) {
> > > - dev_priv->cdclk_pll.vco = 0;
> > > + if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
> > >   return;
> > > - }
> > >  
> > > - WARN_ON((val & BXT_DE_PLL_LOCK) == 0);
> > > + if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
> > > + return;
> > >  
> > >   val = I915_READ(BXT_DE_PLL_CTL);
> > >   dev_priv->cdclk_pll.vco = (val & BXT_DE_PLL_RATIO_MASK) *
> > > -- 
> > > 2.5.0
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Imre Deak]

On ti, 2016-05-24 at 13:22 +0300, Ville Syrjälä wrote:
> On Tue, May 24, 2016 at 12:27:50PM +0300, Imre Deak wrote:
> > If the CDCLK PLL isn't locked we can just assume that it's off resulting
> > in fully re-initializing both CDCLK PLL and CDCLK dividers. This way the
> > CDCLK PLL sanitization added in the following patch can be done on BXT
> > the same way as it's done on SKL.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 23 +++
> >  1 file changed, 11 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index c1e666b..b8e5995 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5461,14 +5461,14 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
> >     u32 val;
> >  
> >     dev_priv->cdclk_pll.ref = 24000;
> > +   dev_priv->cdclk_pll.vco = 0;
> >  
> >     val = I915_READ(LCPLL1_CTL);
> > -   if ((val & LCPLL_PLL_ENABLE) == 0) {
> > -   dev_priv->cdclk_pll.vco = 0;
> > +   if ((val & LCPLL_PLL_ENABLE) == 0)
> >     return;
> > -   }
> >  
> > -   WARN_ON((val & LCPLL_PLL_LOCK) == 0);
> > +   if (WARN_ON((val & LCPLL_PLL_LOCK) == 0))
> > +   return;
> >  
> >     val = I915_READ(DPLL_CTRL1);
> >  
> > @@ -5690,9 +5690,10 @@ static void skl_sanitize_cdclk(struct 
> > drm_i915_private *dev_priv)
> >     if ((I915_READ(SWF_ILK(0x18)) & 0x00FF) == 0)
> >     goto sanitize;
> >  
> > +   intel_update_cdclk(dev_priv->dev);
> >     /* Is PLL enabled and locked ? */
> > -   if ((I915_READ(LCPLL1_CTL) & (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK)) !=
> > -   (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK))
> > +   if (!dev_priv->cdclk_pll.vco ||
> 
> == 0 please. I find that more pleasing to the eye when we end up mixing
> with == anyway on the next line.

Ok.

> Actually is there any extra benefit from the cdclk_freq check? As
> in would vco==0 be sufficient on its own?

The other check is for the case of an invalid CDCLK divider setting.
Don't we care about that?

> > +   dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
> >     goto sanitize;
> >  
> >     if ((I915_READ(DPLL_CTRL1) & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
> 
> Maybe toss out this DPLL_CTRL1 check that I added as well then, and have
> skl_dpll0_update() set the vco to 0 when it's crap. If we ever actually
> hit this in the real world, we'll get the warn, and then we perhaps get
> to rethink this stuff, but for now simpler seems better.

Ok, makes sense.

> > @@ -5701,8 +5702,6 @@ static void skl_sanitize_cdclk(struct 
> > drm_i915_private *dev_priv)
> >     DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
> >     goto sanitize;
> >  
> > -   intel_update_cdclk(dev_priv->dev);
> > -
> >     /* DPLL okay; verify the cdclock
> >      *
> >      * Noticed in some instances that the freq selection is correct but
> > @@ -6608,14 +6607,14 @@ static void bxt_de_pll_update(struct 
> > drm_i915_private *dev_priv)
> >     u32 val;
> >  
> >     dev_priv->cdclk_pll.ref = 19200;
> > +   dev_priv->cdclk_pll.vco = 0;
> >  
> >     val = I915_READ(BXT_DE_PLL_ENABLE);
> > -   if ((val & BXT_DE_PLL_PLL_ENABLE) == 0) {
> > -   dev_priv->cdclk_pll.vco = 0;
> > +   if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
> >     return;
> > -   }
> >  
> > -   WARN_ON((val & BXT_DE_PLL_LOCK) == 0);
> > +   if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
> > +   return;
> >  
> >     val = I915_READ(BXT_DE_PLL_CTL);
> >     dev_priv->cdclk_pll.vco = (val & BXT_DE_PLL_RATIO_MASK) *
> > -- 
> > 2.5.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix warnings from atomic nonblocking unpin.

[Patchwork]

== Series Details ==

Series: drm/i915: Fix warnings from atomic nonblocking unpin.
URL   : https://patchwork.freedesktop.org/series/7629/
State : failure

== Summary ==

Series 7629v1 drm/i915: Fix warnings from atomic nonblocking unpin.
http://patchwork.freedesktop.org/api/1.0/series/7629/revisions/1/mbox

Test gem_basic:
Subgroup create-close:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_busy:
Subgroup basic-parallel-vebox:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Subgroup basic-default-interruptible:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> FAIL   (ro-byt-n2820)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-WARN (ro-skl-i7-6700hq)
Test pm_rps:
Subgroup basic-api:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:177  dwarn:6   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
fi-bsw-n3050 failed to connect after reboot
fi-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_991/

8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration manifest
bfcb12e Revert "drm/i915: Allow nonblocking update of pageflips."
5be06c1 drm/i915: Throttle cursor flip updates.
951d3ff drm/i915: Bump pin_count to 255.
5aa8070 drm/i915: Wait for flips to complete before returning.

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable automatic GuC firmware loading

[Tvrtko Ursulin]

On 24/05/16 12:12, Chris Wilson wrote:

On Mon, May 23, 2016 at 04:34:35PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

New GuC code is logging errors at runtime suspend and resume which
causes CI testing to log "orange" status. Default to not trying to
load the firmware until this is resolved.

Example of the log:

  [drm] RC6 on
  [drm:intel_runtime_suspend] Suspending device
  [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x501 failed. 
ret=-110 status=0x0501 response=0x4000
  ...
  [drm:intel_runtime_resume] Resuming device
  [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x502 failed. 
ret=-110 status=0x0502 response=0x4000
  [drm:intel_runtime_resume] Device resumed

Signed-off-by: Tvrtko Ursulin 
Cc: Dave Gordon 
Cc: Ville Syrjälä 
Cc: Chris Harris 
---
  drivers/gpu/drm/i915/i915_params.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 21a323c01cdb..9a5d58b251f5 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -53,7 +53,7 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = -1,
+   .enable_guc_loading = 0,
.enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
@@ -197,7 +197,7 @@ MODULE_PARM_DESC(edp_vswing,
  module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
  MODULE_PARM_DESC(enable_guc_loading,
"Enable GuC firmware loading "
-   "(-1=auto [default], 0=never, 1=if available, 2=required)");
+   "(-1=auto, 0=never [default], 1=if available, 2=required)");

  module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
  MODULE_PARM_DESC(enable_guc_submission,


Patch does what it says on the tin,
Reviewed-by: Chris Wilson 

Not thrilled by the [soft] ABI of i915.enable_guc_loading though.
That looks like an internal dependency of various GuC enabled features
and not a standalone feature that the user should be controlling.


Merged, thanks for the patch and review.

Wider discussion on params I suppose when Dave gets back.

Regards,

Tvrtko

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

[Intel-gfx] [PATCH v2 4/4] Revert "drm/i915: Allow nonblocking update of pageflips."

[Maarten Lankhorst]

This reverts commit d55dbd06bb5e1399aba9ab5227465339d1bbefff.

It lacks a description, removes the flip trace point,
doesn't handle -EBUSY if a flip is already queued
and needs to be redone.

Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 350 ++-
 1 file changed, 266 insertions(+), 84 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 876484270cd2..5fd0ef22aabe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -108,6 +108,8 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
 static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
+static void intel_begin_crtc_commit(struct drm_crtc *, struct drm_crtc_state 
*);
+static void intel_finish_crtc_commit(struct drm_crtc *, struct drm_crtc_state 
*);
 static void skl_init_scalers(struct drm_device *dev, struct intel_crtc 
*intel_crtc,
struct intel_crtc_state *crtc_state);
 static void skylake_pfit_enable(struct intel_crtc *crtc);
@@ -10984,7 +10986,7 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_request *req;
-   int i, ret;
+   int i;
 
if (!needs_modeset(_state->base) && crtc_state->update_pipe) {
work->put_power_domains =
@@ -11006,14 +11008,7 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
_priv->rps.mmioflips));
}
 
-   ret = drm_crtc_vblank_get(crtc);
-   I915_STATE_WARN(ret < 0, "enabling vblank failed with %i\n", ret);
-
-   if (work->num_planes &&
-   work->old_plane_state[0]->base.plane == crtc->primary)
-   intel_fbc_enable(intel_crtc, work->new_crtc_state, 
work->new_plane_state[0]);
-
-   intel_frontbuffer_flip_prepare(dev, work->fb_bits);
+   intel_frontbuffer_flip_prepare(dev, crtc_state->fb_bits);
 
intel_pipe_update_start(intel_crtc);
if (!needs_modeset(_state->base)) {
@@ -11032,15 +11027,206 @@ static void intel_mmio_flip_work_func(struct 
work_struct *w)
struct intel_plane_state *new_plane_state = 
work->new_plane_state[i];
struct intel_plane *plane = 
to_intel_plane(new_plane_state->base.plane);
 
-   if (new_plane_state->visible)
-   plane->update_plane(>base, crtc_state, 
new_plane_state);
-   else
-   plane->disable_plane(>base, crtc);
+   plane->update_plane(>base, crtc_state, new_plane_state);
}
 
intel_pipe_update_end(intel_crtc, work);
 }
 
+static struct fence *intel_get_excl_fence(struct drm_i915_gem_object *obj)
+{
+   struct reservation_object *resv;
+
+
+   if (!obj->base.dma_buf)
+   return NULL;
+
+   resv = obj->base.dma_buf->resv;
+
+   /* For framebuffer backed by dmabuf, wait for fence */
+   while (1) {
+   struct fence *fence_excl, *ret = NULL;
+
+   rcu_read_lock();
+
+   fence_excl = rcu_dereference(resv->fence_excl);
+   if (fence_excl)
+   ret = fence_get_rcu(fence_excl);
+
+   rcu_read_unlock();
+
+   if (ret == fence_excl)
+   return ret;
+   }
+}
+
+static int intel_crtc_page_flip(struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   struct drm_pending_vblank_event *event,
+   uint32_t page_flip_flags)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_plane_state *old_state, *new_state = NULL;
+   struct drm_crtc_state *new_crtc_state = NULL;
+   struct drm_framebuffer *old_fb = crtc->primary->state->fb;
+   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_plane *primary = crtc->primary;
+   struct intel_flip_work *work;
+   int ret;
+
+   old_state = crtc->primary->state;
+
+   if (!crtc->state->active)
+   return -EINVAL;
+
+   /*
+* drm_mode_page_flip_ioctl() should already catch this, but double
+* check to be safe.  In the future we may enable pageflipping from
+* a disabled primary plane.
+*/
+   if (WARN_ON(intel_fb_obj(old_fb) == NULL))
+   return -EBUSY;
+
+   /* Can't change pixel format via MI display flips. */
+   if (fb->pixel_format != old_fb->pixel_format)
+   return 

[Intel-gfx] [PATCH v2 3/4] drm/i915: Throttle cursor flip updates.

[Maarten Lankhorst]

Throttle after every vblank and when > 64 updates are queued, to prevent running
higher than max pin count.

For now there's no good way to do fold crtc updates, and to ensure that
we don't run out of cursor pins the best option is to throttle.

Testcase: kms_cursor_legacy
Cc: Ville Syrjälä 
Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 21c0a2f3102b..876484270cd2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12740,14 +12740,22 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_flip_work *work;
 
-   if (!state->legacy_cursor_update) {
+   if (!state->legacy_cursor_update ||
+   atomic_read(_crtc->unpin_work_count) >= 64) {
ret = intel_crtc_wait_for_pending_flips(crtc, true);
if (ret)
return ret;
 
if (atomic_read(_crtc->unpin_work_count) >= 2)
flush_workqueue(dev_priv->wq);
-   }
+   } else if (list_empty_careful(_crtc->flip_work) &&
+  atomic_read(_crtc->unpin_work_count) >= 2)
+   /*
+* When running a legacy_cursor_update only load,
+* unpin_work may never run. Flush after a vblank
+* happened to ensure it does.
+*/
+   flush_workqueue(dev_priv->wq);
 
/* test if we need to update something */
if (!needs_work(crtc_state))
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 0/4] drm/i915: Fix warnings from atomic nonblocking unpin.

[Maarten Lankhorst]

New version with other approach to fix cursor updates.
Pin count is bumped only to 255 to make it more likely to hit,
and each crtc can only have 64 updates queued. This will make it
impossible to hit the bo pinning limit.

It also has the revert for nonblocking update of pageflips,
since that patch needs to be redone.

Maarten Lankhorst (4):
  drm/i915: Wait for flips to complete before returning.
  drm/i915: Bump pin_count to 255.
  drm/i915: Throttle cursor flip updates.
  Revert "drm/i915: Allow nonblocking update of pageflips."

 drivers/gpu/drm/i915/i915_gem_gtt.h  |   4 +-
 drivers/gpu/drm/i915/intel_display.c | 386 ++-
 2 files changed, 297 insertions(+), 93 deletions(-)

-- 
2.5.5

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

[Intel-gfx] [PATCH v2 2/4] drm/i915: Bump pin_count to 255.

[Maarten Lankhorst]

With nonblocking unpin there can be many cursor pins before they're
cleared by the next page flip.

Fix this by extending pin_count to 255 to prevent a
WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)

Cc: Ville Syrjälä 
Reported-by: Chris Wilson 
Signed-off-by: Maarten Lankhorst 
Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
---
 drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 62be77cac5cd..bb53c285eef7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -218,8 +218,8 @@ struct i915_vma {
 *
 * In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
 * bits with absolutely no headroom. So use 4 bits. */
-   unsigned int pin_count:4;
-#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 0xf
+   unsigned int pin_count;
+#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 255
 };
 
 struct i915_page_dma {
-- 
2.5.5

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

[Intel-gfx] [PATCH v2 1/4] drm/i915: Wait for flips to complete before returning.

[Maarten Lankhorst]

Doing a page flip right after setcrtc would fail because part of the update is 
run
asynchronously. This is a regression and is causing the kms_flip to fails after
reverting the atomic page flip patch.

Signed-off-by: Maarten Lankhorst 
Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
---
 drivers/gpu/drm/i915/intel_display.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a500f08ec0ac..21c0a2f3102b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3788,7 +3788,7 @@ static void page_flip_completed(struct intel_crtc 
*intel_crtc, struct intel_flip
queue_work(dev_priv->wq, >unpin_work);
 }
 
-static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
+static int intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc, bool intr)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3796,10 +3796,15 @@ static int intel_crtc_wait_for_pending_flips(struct 
drm_crtc *crtc)
 
WARN_ON(waitqueue_active(_priv->pending_flip_queue));
 
-   ret = wait_event_interruptible_timeout(
-   dev_priv->pending_flip_queue,
-   !intel_crtc_has_pending_flip(crtc),
-   60*HZ);
+   if (intr)
+   ret = wait_event_interruptible_timeout(
+   dev_priv->pending_flip_queue,
+   
!intel_crtc_has_pending_flip(crtc),
+   60*HZ);
+   else
+   ret = wait_event_timeout(dev_priv->pending_flip_queue,
+!intel_crtc_has_pending_flip(crtc),
+60*HZ);
 
if (ret < 0)
return ret;
@@ -12736,7 +12741,7 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
struct intel_flip_work *work;
 
if (!state->legacy_cursor_update) {
-   ret = intel_crtc_wait_for_pending_flips(crtc);
+   ret = intel_crtc_wait_for_pending_flips(crtc, true);
if (ret)
return ret;
 
@@ -13005,6 +13010,7 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
int ret = 0, i;
+   unsigned crtc_mask = 0;
 
ret = intel_atomic_prepare_commit(dev, state, nonblock);
if (ret) {
@@ -13075,6 +13081,8 @@ static int intel_atomic_commit(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
 
+   crtc_mask |= drm_crtc_mask(crtc);
+
if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
@@ -13105,6 +13113,12 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_schedule_update(crtc, intel_state, work, nonblock);
}
 
+   if (!nonblock && !state->legacy_cursor_update) {
+   drm_for_each_crtc(crtc, dev)
+   if (crtc_mask & drm_crtc_mask(crtc))
+   intel_crtc_wait_for_pending_flips(crtc, false);
+   }
+
/* FIXME: add subpixel order */
 
drm_atomic_state_free(state);
-- 
2.5.5

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Skip idling an idle engine

[Patchwork]

== Series Details ==

Series: drm/i915: Skip idling an idle engine
URL   : https://patchwork.freedesktop.org/series/7628/
State : failure

== Summary ==

Series 7628v1 drm/i915: Skip idling an idle engine
http://patchwork.freedesktop.org/api/1.0/series/7628/revisions/1/mbox

Test gem_busy:
Subgroup basic-parallel-vebox:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Subgroup basic-render:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_basic:
Subgroup readonly-blt:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)
Subgroup basic-wb-prw-default:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_linear_blits:
Subgroup basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ringfill:
Subgroup basic-default-interruptible:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_sink_crc_basic:
pass   -> SKIP   (ro-skl-i7-6700hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-WARN (ro-skl-i7-6700hq)
Test pm_rps:
Subgroup basic-api:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:169  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:174  dwarn:8   dfail:0   fail:0   skip:22 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_990/

8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration manifest
af35cac drm/i915: Skip idling an idle engine

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

Re: [Intel-gfx] [PATCH v2 04/11] drm/i915: Rename i915_gem_context_reference/unreference()

[Chris Wilson]

On Mon, May 23, 2016 at 12:34:11PM +0100, Chris Wilson wrote:
> As these are wrappers around kref_get/kref_put() it is preferable to
> follow the naming convention and use the same verb get/put in our
> wrapper names for manipulating a reference to the context.
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 

The consensus is to punt this until we have more consistency (i.e.
converting a bunch of objects over).
-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 v3] drm/i915/debugfs: Show context objects in i915_gem_objects

[Tvrtko Ursulin]

On 23/05/16 14:01, Chris Wilson wrote:

One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
can compare the number of allocated objects and who owns them, a
discrepancy here often indicates a kernel bug. One allocator of unreported
objects is for backing context objects, so include those in the listing.

v2: Take filelist_mutex which requires a little dance with struct_mutex
to avoid nesting filelist_mutex inside struct_mutex.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 38 -
  1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 30cb26fe2fa9..1300bad67f5c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -417,6 +417,42 @@ static void print_batch_pool_stats(struct seq_file *m,
print_file_stats(m, "[k]batch pool", stats);
  }

+static int per_file_ctx_stats(int id, void *ptr, void *data)
+{
+   struct i915_gem_context *ctx = ptr;
+   int n;
+
+   for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
+   if (ctx->engine[n].state)
+   per_file_stats(0, ctx->engine[n].state, data);
+   if (ctx->engine[n].ringbuf)
+   per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
+   }
+
+   return 0;
+}
+
+static void print_context_stats(struct seq_file *m,
+   struct drm_i915_private *dev_priv)
+{
+   struct file_stats stats;
+   struct drm_file *file;
+
+   memset(, 0, sizeof(stats));
+
+   mutex_lock(_priv->dev->struct_mutex);
+   if (dev_priv->kernel_context)
+   per_file_ctx_stats(0, dev_priv->kernel_context, );
+
+   list_for_each_entry(file, _priv->dev->filelist, lhead) {
+   struct drm_i915_file_private *fpriv = file->driver_priv;
+   idr_for_each(>context_idr, per_file_ctx_stats, );
+   }
+   mutex_unlock(_priv->dev->struct_mutex);
+
+   print_file_stats(m, "[k]contexts", stats);
+}
+
  #define count_vmas(list, member) do { \
list_for_each_entry(vma, list, member) { \
size += i915_gem_obj_total_ggtt_size(vma->obj); \
@@ -521,10 +557,10 @@ static int i915_gem_object_info(struct seq_file *m, void* 
data)

seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
-
mutex_unlock(>struct_mutex);

mutex_lock(>filelist_mutex);
+   print_context_stats(m, dev_priv);
list_for_each_entry_reverse(file, >filelist, lhead) {
struct file_stats stats;
struct task_struct *task;



Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH i-g-t v5 0/7] kms_flip_event_leak and kms_vblank fixes for

[Marius Vlad]

Hi,

I'm getting mixed results w/ this series applied. The kernel seems to
trip in different ways either from suspend or on reload (running the BAT
suite on a HSW machine), and though it seems totally
unrelated I can't reproduce the same behaviour without the series
applied. Haven't managed to get some valid output as the machine
dead-locks/freezes, so please be patient until I try to isolate the
problem. It could be I stumbled something totally unrelated.


On Mon, May 16, 2016 at 09:38:25AM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> In addition to the changes made in v4, danvet suggested that the argument for
> the (newly renamed) helper function kmstest_get_vbl_flag should be changed.
> 
> I investigated it and found that all of the places where the helper function
> currently is used, would require more of a rework with changed arguments than
> with unchanged arguments, so I decided to not change the arguments.
> 
> Changes since v1:
> - kms_vblank: Removed un-used members of data_t struct.
> - Rename plane_counter to n_planes.
> - Removed un-needed handling CURSOR plane location.
> - Added names for additional planes in update kmstest_plane_name.
> 
> Changes since v2:
> - Rebased onto trunk which already contains kms_flip_event_leak changes.
> 
> Changes since v3:
> - kms_vblank.c: Removed drm_fd from data_t, to decrease the number of
> unrelated changes in the patch.
> - kms_vblank.c: Changed "int valid_tests" to "unsigned valid_tests".
> - kms_vblank.c: Changed crtc_id_flag/crtc_id_to_flag to
> pipe_id_flag/pipe_id_to_flag.
> - kms_vblank.c: Changed to "vbl.request.type |= crtc_id_flag;".
> - kms_vblank.c: Moved crtc_id_to_flag to igt_kms.c.
> - kms_vblank.c: Renamed crtc_id_to_flag to pipe_id_to_vbl_flag.
> - kms_flip.c: Changed test busy_mode boolean into mode_busy bitfield in struct
> data.
> - igt_kms.h: Moved IGT_PLANE_CURSOR position comment.
> 
> Changes since v4:
> - kms_vblank.c: Removed whitespace at end of file.
> - igt_kms: Changed name of helper function to kmstest_get_vbl_flag
> - igt_kms: Changed kmstest_get_vbl_flag to not set DRM_VBLANK_RELATIVE flag
> 
> Robert Foss (7):
>   lib/igt_kms: Add support for up to 10 planes.
>   lib/igt_kms: Fix plane counting in igt_display_init.
>   lib/igt_kms: Switch to verbose assert.
>   lib/igt_kms: Added pipe_id_to_vbl_flag() to igt_kms.
>   kms_vblank: Switch from using crtc0 statically to explicitly setting
> mode.
>   igt_kms: Change igt_wait_for_vblank to use helper function.
>   kms_flip: Change __wait_for_vblank to use helper function.
> 
>  lib/igt_kms.c  |  36 ++--
>  lib/igt_kms.h  |   9 ++-
>  tests/kms_flip.c   |   8 +--
>  tests/kms_vblank.c | 161 
> -
>  4 files changed, 179 insertions(+), 35 deletions(-)
> 
> -- 
> 2.7.4
> 


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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Disable automatic GuC firmware loading

[Chris Wilson]

On Mon, May 23, 2016 at 04:34:35PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> New GuC code is logging errors at runtime suspend and resume which
> causes CI testing to log "orange" status. Default to not trying to
> load the firmware until this is resolved.
> 
> Example of the log:
> 
>  [drm] RC6 on
>  [drm:intel_runtime_suspend] Suspending device
>  [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x501 failed. 
> ret=-110 status=0x0501 response=0x4000
>  ...
>  [drm:intel_runtime_resume] Resuming device
>  [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x502 failed. 
> ret=-110 status=0x0502 response=0x4000
>  [drm:intel_runtime_resume] Device resumed
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Dave Gordon 
> Cc: Ville Syrjälä 
> Cc: Chris Harris 
> ---
>  drivers/gpu/drm/i915/i915_params.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 21a323c01cdb..9a5d58b251f5 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -53,7 +53,7 @@ struct i915_params i915 __read_mostly = {
>   .verbose_state_checks = 1,
>   .nuclear_pageflip = 0,
>   .edp_vswing = 0,
> - .enable_guc_loading = -1,
> + .enable_guc_loading = 0,
>   .enable_guc_submission = 0,
>   .guc_log_level = -1,
>   .enable_dp_mst = true,
> @@ -197,7 +197,7 @@ MODULE_PARM_DESC(edp_vswing,
>  module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
> 0400);
>  MODULE_PARM_DESC(enable_guc_loading,
>   "Enable GuC firmware loading "
> - "(-1=auto [default], 0=never, 1=if available, 2=required)");
> + "(-1=auto, 0=never [default], 1=if available, 2=required)");
>  
>  module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
> int, 0400);
>  MODULE_PARM_DESC(enable_guc_submission,

Patch does what it says on the tin,
Reviewed-by: Chris Wilson 

Not thrilled by the [soft] ABI of i915.enable_guc_loading though.
That looks like an internal dependency of various GuC enabled features
and not a standalone feature that the user should be controlling.
-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 v3 2/2] drm/i915: Render decompression support for Gen9 and above

[Kannan, Vandana]

Hi Ville,

Did you get a chance to review this patch?

- Vandana

> -Original Message-
> From: Kannan, Vandana
> Sent: Friday, May 13, 2016 7:35 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kannan, Vandana ; Ville Syrjälä
> ; Smith, Gary K 
> Subject: [PATCH v3 2/2] drm/i915: Render decompression support for
> Gen9 and above
> 
> This patch includes enabling render decompression (RC) after checking all
> the requirements (format, tiling, rotation etc.).
> 
> TODO:
> 1. Disable stereo 3D when render decomp is enabled (bit 7:6) 2. Render
> decompression must not be used in VTd pass-through mode 3. Program
> hashing select CHICKEN_MISC1 bit 15 4. For Gen10, add support for RGB
> 1010102 5. RC-FBC workaround 6. RC watermark calculation
> 
> The reason for using a plane property instead of fb modifier:- In Android,
> OGL passes a render compressed buffer to hardware composer (HWC),
> which would then request a flip on that buffer after checking if the target
> can support render compressed buffer. For example, only planes
> 1 and 2 on pipes 1 and 2 can support RC. In case the target cannot
> support it, HWC will revert back to OGL requesting for uncompressed
> buffer.
> Here,
> if plane property is used, OGL would send back the buffer (same ID) after
> decompression, marked uncompressed. If fb modifier was used, a different
> version of the buffer would have to be maintained for different
> combinations - in the simple case of render compressed vs uncompressed
> buffer, there would be 2 fbs with 2 IDs. So, in this case, OGL would give a
> reference to a fb with a different ID.
> To avoid the difficulty of keeping track of multiple fbs and the
> subsequent complexity in debug, the architecture forum decided to go
> ahead with a plane property for RC.
> 
> [Mayuresh] Added the plane check in skl_check_compression()
> 
> v2: Ville's review comments addressed
> - Removed WAs specific to SKL-C and BXT-A
> - Assign capabilities according to pipe and plane during property creation
> - in skl_check_compression(), check for conditions that must be satisifed
> 
> Maintaining the check for pixel format, even though compressed fb of
> format other RGB should not have been created, to be on the safer
> side.
> Added checks for BGR too.
> Bitmask is being used for the property to accommodate 2 more options
> expected to be added in future.
> 
> v3: This patch has been implemented on top of Ville's patch series on
> fb->offsets.
> (Ref: git://github.com/vsyrjala/linux.git fb_offsets_15)
> - Userspace is expected to pass aux offset through fb->offsets[1].
> 
> Testing is in progress for v3 of the patch.
> 
> Signed-off-by: Vandana Kannan 
> Cc: Ville Syrjälä 
> Cc: Smith, Gary K 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |   1 +
>  drivers/gpu/drm/i915/i915_reg.h   |  22 ++
>  drivers/gpu/drm/i915/intel_atomic_plane.c |  24 +--
>  drivers/gpu/drm/i915/intel_display.c  | 111
> ++
>  drivers/gpu/drm/i915/intel_drv.h  |  10 +++
>  drivers/gpu/drm/i915/intel_sprite.c   |  13 
>  6 files changed, 177 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 7a0b513..0465e0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1915,6 +1915,7 @@ struct drm_i915_private {
> 
>   struct drm_property *broadcast_rgb_property;
>   struct drm_property *force_audio_property;
> + struct drm_property *render_comp_property;
> 
>   /* hda/i915 audio component */
>   struct i915_audio_component *audio_component; diff --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 54ce0b1..9d008e1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5818,6 +5818,28 @@ enum skl_disp_power_wells {
>   _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
>   _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> 
> +#define PLANE_AUX_DIST_1_A   0x701c0
> +#define PLANE_AUX_DIST_2_A   0x702c0
> +#define PLANE_AUX_DIST_1_B   0x711c0
> +#define PLANE_AUX_DIST_2_B   0x712c0
> +#define _PLANE_AUX_DIST_1(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_1_A,
> PLANE_AUX_DIST_1_B) #define
> +_PLANE_AUX_DIST_2(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_2_A,
> PLANE_AUX_DIST_2_B)
> +#define PLANE_AUX_DIST(pipe, plane) \
> + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> _PLANE_AUX_DIST_2(pipe))
> +
> +#define PLANE_AUX_OFFSET_1_A 0x701c4
> +#define PLANE_AUX_OFFSET_2_A 0x702c4
> +#define PLANE_AUX_OFFSET_1_B 0x711c4
> +#define PLANE_AUX_OFFSET_2_B 0x712c4
> +#define _PLANE_AUX_OFFSET_1(pipe)   \
> + 

[Intel-gfx] [PATCH] drm/i915: Skip idling an idle engine

[Chris Wilson]

During suspend (or module unload), if we have never accessed the engine
(i.e. userspace never submitted a batch to it), the engine is idle. Then
we attempt to idle the engine by forcing it to the default context,
which actually means we submit a render batch to setup the golden
context state and then wait for it to complete. We can skip this
entirely as we know the engine is idle.

Testcase: igt/drm_module_reload_basic #byt
Signed-off-by: Chris Wilson 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95634
---
 drivers/gpu/drm/i915/i915_gem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b3c15698d611..8fb4fe6ae98c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3428,6 +3428,9 @@ int i915_gpu_idle(struct drm_device *dev)
 
/* Flush everything onto the inactive list. */
for_each_engine(engine, dev_priv) {
+   if (engine->last_context == NULL)
+   continue;
+
if (!i915.enable_execlists) {
struct drm_i915_gem_request *req;
 
-- 
2.8.1

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

Re: [Intel-gfx] [RFC][PATCH 3/3] drm/i915: Make RPS enable immediate

[Chris Wilson]

On Tue, May 24, 2016 at 01:14:53PM +0300, Ville Syrjälä wrote:
> On Tue, May 24, 2016 at 10:27:19AM +0200, Daniel Vetter wrote:
> > On Mon, May 23, 2016 at 05:09:43PM +0300, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > On SNB (at least) it's dangeruopus to hang the GPU with an infinite
> > > batch buffer loop while RPS is disabled. The only thing that keeps
> > > the system going in such circumstances are the internal RPS timers,
> > > so we should never feed the GPU with RPS disabled unless we want to
> > > risk a total system hang.
> > > 
> > > Previously we didn't fully disable RPS, but that changes in
> > > commit 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> > > register")
> > > so we probably didn't see the problem so often previously. But
> > > even before that we were at the mercy of the BIOS for the initial
> > > RPS state, so if the BIOS didn't enable RPS a GPU hang immediately
> > > upon boot could have been fatal.
> > > 
> > > To avoid the problems let's just make the RPS enable immediate.
> > > This renders the delayed_resume_work useless actually. We could perhaps
> > > just move the ring freq table initialization to the work and do the
> > > other stull synchronously?
> > > 
> > > Fixes: 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> > > register")
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > > This is more and RFC at this point. Perhaps we might want to keep the 
> > > delayed
> > > work but just for the ring freq table update (which is the main reson 
> > > this whole
> > > thing exists in the first place). Another factor is that wait_for() is not
> > > exactly optiomal currently, so it makes the operation slower than it 
> > > needs to
> > > be. Would need some hard numbers to see if it's worth keeping the delayed 
> > > work
> > > or not I suppose.
> > 
> > Loading the ring freq tables takes forever, so definitely want to keep
> > that.
> 
> It only takes forever becasue wait_for() sucks.
> 
> with current sleep duration of 1000-2000 us:
> [  308.231364] rps init took 5533 us
> [  308.266322] ring freq init took 34952 us
> 
> sleep duration reduced to 100-200 us:
> [  155.367588] rps init took 679 us
> [  155.371100] ring freq init took 3509 us
> 
> So looks like someone just failed to root cause the slowness, and then
> went on to optimize the wrong thing.

It's still 4ms that can be done in parallel to userspace starting :)
(And looks can be reduced further with an smarter wait_for).

So we encourage Mika to send his updated patches...
-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] ✗ Ro.CI.BAT: failure for drm/i915/guc: Disable automatic GuC firmware loading

[Tvrtko Ursulin]

On 24/05/16 06:50, Patchwork wrote:

== Series Details ==

Series: drm/i915/guc: Disable automatic GuC firmware loading
URL   : https://patchwork.freedesktop.org/series/7577/
State : failure

== Summary ==

Series 7577v1 drm/i915/guc: Disable automatic GuC firmware loading
http://patchwork.freedesktop.org/api/1.0/series/7577/revisions/1/mbox

Test drv_module_reload_basic:
 pass   -> DMESG-WARN (ro-byt-n2820)


Re-appearance of  "HW access outside of RPM atomic section", filed new 
https://bugs.freedesktop.org/show_bug.cgi?id=95634.



Test gem_busy:
 Subgroup basic-parallel-vebox:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_ctx_create:
 Subgroup basic:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)


Unrelated " *ERROR* Potential atomic update failure on pipe A", filed 
new https://bugs.freedesktop.org/show_bug.cgi?id=95632.



Test gem_exec_flush:
 Subgroup basic-wb-rw-default:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_exec_suspend:
 Subgroup basic:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)


More of https://bugs.freedesktop.org/show_bug.cgi?id=95632.


Test gem_ringfill:
 Subgroup basic-default-interruptible:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
 Subgroup basic-default:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_flip:
 Subgroup basic-flip-vs-wf_vblank:
 pass   -> FAIL   (ro-bdw-i7-5600u)


Unrelated https://bugs.freedesktop.org/show_bug.cgi?id=94294


Test kms_frontbuffer_tracking:
 Subgroup basic:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_pipe_crc_basic:
 Subgroup bad-pipe:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_psr_sink_crc:
 Subgroup psr_basic:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_setmode:
 Subgroup basic-clone-single-crtc:
 pass   -> DMESG-WARN (ro-skl-i7-6700hq)


More of https://bugs.freedesktop.org/show_bug.cgi?id=95632.


Test pm_rpm:
 Subgroup basic-pci-d3-state:
 fail   -> PASS   (ro-skl-i7-6700hq)
 Subgroup basic-rte:
 dmesg-warn -> PASS   (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12
ro-bdw-i7-5600u  total:209  pass:179  dwarn:0   dfail:0   fail:2   skip:28
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39
ro-byt-n2820 total:209  pass:169  dwarn:1   dfail:0   fail:2   skip:37
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28
ro-skl-i7-6700hq total:204  pass:175  dwarn:8   dfail:0   fail:0   skip:21
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38

Results at /archive/results/CI_IGT_test/RO_Patchwork_981/

8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration manifest
2961287 drm/i915/guc: Disable automatic GuC firmware loading


So it is just missing an r-b.

Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Ville Syrjälä]

On Tue, May 24, 2016 at 12:27:50PM +0300, Imre Deak wrote:
> If the CDCLK PLL isn't locked we can just assume that it's off resulting
> in fully re-initializing both CDCLK PLL and CDCLK dividers. This way the
> CDCLK PLL sanitization added in the following patch can be done on BXT
> the same way as it's done on SKL.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c1e666b..b8e5995 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5461,14 +5461,14 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
>   u32 val;
>  
>   dev_priv->cdclk_pll.ref = 24000;
> + dev_priv->cdclk_pll.vco = 0;
>  
>   val = I915_READ(LCPLL1_CTL);
> - if ((val & LCPLL_PLL_ENABLE) == 0) {
> - dev_priv->cdclk_pll.vco = 0;
> + if ((val & LCPLL_PLL_ENABLE) == 0)
>   return;
> - }
>  
> - WARN_ON((val & LCPLL_PLL_LOCK) == 0);
> + if (WARN_ON((val & LCPLL_PLL_LOCK) == 0))
> + return;
>  
>   val = I915_READ(DPLL_CTRL1);
>  
> @@ -5690,9 +5690,10 @@ static void skl_sanitize_cdclk(struct drm_i915_private 
> *dev_priv)
>   if ((I915_READ(SWF_ILK(0x18)) & 0x00FF) == 0)
>   goto sanitize;
>  
> + intel_update_cdclk(dev_priv->dev);
>   /* Is PLL enabled and locked ? */
> - if ((I915_READ(LCPLL1_CTL) & (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK)) !=
> - (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK))
> + if (!dev_priv->cdclk_pll.vco ||

== 0 please. I find that more pleasing to the eye when we end up mixing
with == anyway on the next line.

Actually is there any extra benefit from the cdclk_freq check? As
in would vco==0 be sufficient on its own?

> + dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
>   goto sanitize;
>  
>   if ((I915_READ(DPLL_CTRL1) & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |

Maybe toss out this DPLL_CTRL1 check that I added as well then, and have
skl_dpll0_update() set the vco to 0 when it's crap. If we ever actually
hit this in the real world, we'll get the warn, and then we perhaps get
to rethink this stuff, but for now simpler seems better.

> @@ -5701,8 +5702,6 @@ static void skl_sanitize_cdclk(struct drm_i915_private 
> *dev_priv)
>   DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
>   goto sanitize;
>  
> - intel_update_cdclk(dev_priv->dev);
> -
>   /* DPLL okay; verify the cdclock
>*
>* Noticed in some instances that the freq selection is correct but
> @@ -6608,14 +6607,14 @@ static void bxt_de_pll_update(struct drm_i915_private 
> *dev_priv)
>   u32 val;
>  
>   dev_priv->cdclk_pll.ref = 19200;
> + dev_priv->cdclk_pll.vco = 0;
>  
>   val = I915_READ(BXT_DE_PLL_ENABLE);
> - if ((val & BXT_DE_PLL_PLL_ENABLE) == 0) {
> - dev_priv->cdclk_pll.vco = 0;
> + if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
>   return;
> - }
>  
> - WARN_ON((val & BXT_DE_PLL_LOCK) == 0);
> + if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
> + return;
>  
>   val = I915_READ(BXT_DE_PLL_CTL);
>   dev_priv->cdclk_pll.vco = (val & BXT_DE_PLL_RATIO_MASK) *
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [RFC][PATCH 3/3] drm/i915: Make RPS enable immediate

[Ville Syrjälä]

On Tue, May 24, 2016 at 10:27:19AM +0200, Daniel Vetter wrote:
> On Mon, May 23, 2016 at 05:09:43PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > On SNB (at least) it's dangeruopus to hang the GPU with an infinite
> > batch buffer loop while RPS is disabled. The only thing that keeps
> > the system going in such circumstances are the internal RPS timers,
> > so we should never feed the GPU with RPS disabled unless we want to
> > risk a total system hang.
> > 
> > Previously we didn't fully disable RPS, but that changes in
> > commit 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> > register")
> > so we probably didn't see the problem so often previously. But
> > even before that we were at the mercy of the BIOS for the initial
> > RPS state, so if the BIOS didn't enable RPS a GPU hang immediately
> > upon boot could have been fatal.
> > 
> > To avoid the problems let's just make the RPS enable immediate.
> > This renders the delayed_resume_work useless actually. We could perhaps
> > just move the ring freq table initialization to the work and do the
> > other stull synchronously?
> > 
> > Fixes: 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> > register")
> > Signed-off-by: Ville Syrjälä 
> > ---
> > This is more and RFC at this point. Perhaps we might want to keep the 
> > delayed
> > work but just for the ring freq table update (which is the main reson this 
> > whole
> > thing exists in the first place). Another factor is that wait_for() is not
> > exactly optiomal currently, so it makes the operation slower than it needs 
> > to
> > be. Would need some hard numbers to see if it's worth keeping the delayed 
> > work
> > or not I suppose.
> 
> Loading the ring freq tables takes forever, so definitely want to keep
> that.

It only takes forever becasue wait_for() sucks.

with current sleep duration of 1000-2000 us:
[  308.231364] rps init took 5533 us
[  308.266322] ring freq init took 34952 us

sleep duration reduced to 100-200 us:
[  155.367588] rps init took 679 us
[  155.371100] ring freq init took 3509 us

So looks like someone just failed to root cause the slowness, and then
went on to optimize the wrong thing.

> I'd just split rps setup in two parts and push the schedule_work
> down a bit. Long term we can go overboard with async (and maybey only
> stall for all the GT setup in the very first batchbuffer).
> -Daniel
> 
> > 
> >  drivers/gpu/drm/i915/intel_pm.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 817c84c22782..e65c5c2b9b4e 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6505,6 +6505,7 @@ void intel_enable_gt_powersave(struct 
> > drm_i915_private *dev_priv)
> > if (schedule_delayed_work(_priv->rps.delayed_resume_work,
> >round_jiffies_up_relative(HZ)))
> > intel_runtime_pm_get_noresume(dev_priv);
> > +   flush_delayed_work(_priv->rps.delayed_resume_work);
> > }
> >  }
> >  
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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 1/5] drm/i915: Invoke the DP Compliance test request handler in the short pulse path

[Thulasimani, Sivakumar]

i am bit partial :) coz i was involved but isn't the same done in patch 
shared

earlier ?
https://patchwork.freedesktop.org/patch/82587/

why not integrate that here if something more is done in the following 
patches ?


regards,
Sivakumar

On 4/30/2016 6:58 AM, Manasi Navare wrote:

HPD Short pulse test requests occur for DP Compliance Link Training
and Video Pattern tests.The DP Test request handler needs to be
invoked by these tests in the short pulse path in order to support
automated DP Compliance tests.

Signed-off-by: Manasi Navare 
---
  drivers/gpu/drm/i915/intel_dp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c12c414..19a95ed 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4257,7 +4257,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
   sink_irq_vector);
  
  		if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)

-   DRM_DEBUG_DRIVER("Test request in short pulse not 
handled\n");
+   intel_dp_handle_test_request(intel_dp);
if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}


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

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/2] drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/gen9: Assume CDCLK PLL is off if 
it's not locked
URL   : https://patchwork.freedesktop.org/series/7621/
State : warning

== Summary ==

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

Test gem_busy:
Subgroup basic-parallel-vebox:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_mmap_gtt:
Subgroup basic-read:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ringfill:
Subgroup basic-default-interruptible:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_sink_crc_basic:
pass   -> SKIP   (ro-skl-i7-6700hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-WARN (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:197  dwarn:0   dfail:0   fail:0   skip:12 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:209  pass:170  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:209  pass:146  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:176  dwarn:6   dfail:0   fail:0   skip:22 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 

Results at /archive/results/CI_IGT_test/RO_Patchwork_988/

8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration manifest
764f0ce drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume
8a66284 drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

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

Re: [Intel-gfx] [PATCH] drm/i915/ilk: Wait one vblank before enabling audio

[Jani Nikula]

On Mon, 23 May 2016, Lyude Paul  wrote:
> On Mon, 2016-05-23 at 21:06 +0300, Ville Syrjälä wrote:
>> On Fri, May 20, 2016 at 05:36:40PM -0400, Lyude wrote:
>> > 
>> > We no longer call ilk_audio_codec_enable() while we have vblanks
>> > disabled. As such, we can finally fix this and stop the occasional pipe
>> > underruns I'm seeing on this Dell OptiPlex 990.
>> Hmm. Are you still getting underruns on -nightly?
> For me the problem isn't just underruns, a lot of times the modeset
> results in a blank monitor without this fix… afaict waiting for 1
> vblank seems to fix the issue entirely here, but I'll check more
> thoroughly in a bit and update you if I manage to get it to underrun.

I suppose the question is, do you see the problem also when you rule out
the audio stuff altogether? I.e. does the vblank wait happen to help
independent of the audio?

BR,
Jani.


>
> Cheers,
> Lyude
>
>> 
>> I basically tried this same thing (+ a bunch of other tweaks to the
>> audio enable sequence) when I was hunting the remaining underruns on
>> my ILK, but in the end audio was a red herring. So I never found
>> any real benefit from extra vblank waits in the audio enable sequence.
>> They did appear to help sometimes, but with a enough repetitions it
>> still failed.
>> 
>> > 
>> > 
>> > Cc: sta...@vger.kernel.org
>> > Signed-off-by: Lyude 
>> > ---
>> >  drivers/gpu/drm/i915/intel_audio.c | 8 ++--
>> >  1 file changed, 2 insertions(+), 6 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> > b/drivers/gpu/drm/i915/intel_audio.c
>> > index 7d281b4..0d685fe 100644
>> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > @@ -423,12 +423,8 @@ static void ilk_audio_codec_enable(struct 
>> > drm_connector
>> > *connector,
>> >    if (WARN_ON(port == PORT_A))
>> >    return;
>> >  
>> > -  /*
>> > -   * FIXME: We're supposed to wait for vblank here, but we have
>> > vblanks
>> > -   * disabled during the mode set. The proper fix would be to push
>> > the
>> > -   * rest of the setup into a vblank work item, queued here, but the
>> > -   * infrastructure is not there yet.
>> > -   */
>> > +  /* Need to wait one vblank before enabling audio */
>> > +  intel_wait_for_vblank(connector->dev, pipe);
>> >  
>> >    if (HAS_PCH_IBX(connector->dev)) {
>> >    hdmiw_hdmiedid = IBX_HDMIW_HDMIEDID(pipe);
>> > -- 
>> > 2.5.5
>> > 
>> > ___
>> > dri-devel mailing list
>> > dri-de...@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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/5] drm/i915: Fixes to support the DP Compliance EDID tests.

[Shubhangi Shrivastava]

On Monday 23 May 2016 01:48 PM, Ander Conselvan De Oliveira wrote:

On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:

This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte

Do you mean commit 559be30cb74d ("drm/i915: Implement the intel_dp_autotest_edid
function for DP EDID complaince tests")? Please see the link below on how to
refer to other commits in the commit message and how to add a Fixes: tag.

https://www.kernel.org/doc/Documentation/SubmittingPatches


Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Intel connector status should be connected even if detect_edid is
NULL when compliance_test flag is set. This is required to handle
the corrupt EDID (CTS 4.2.2.6) or EDID Read Failure I2C NACK/I2C
DEFER (CTS 4.2.2.4 and 4.2.2.5) tests from CTS spec.

What exactly do those tests test? It sounds like this patch adds a separate code
path to implement the right behavior only when running the CTS. Shouldn't the
driver handle those failures during normal operation in the same way?


Signed-off-by: Manasi Navare
---
  drivers/gpu/drm/i915/intel_dp.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0961f22..456fc17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4023,7 +4023,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct
intel_dp *intel_dp)
  
  static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)

  {
-   uint8_t test_result = DP_TEST_NAK;
+   uint8_t test_result = DP_TEST_ACK;
struct intel_connector *intel_connector = intel_dp-

attached_connector;

struct drm_connector *connector = _connector->base;
  
@@ -4058,7 +4058,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp

*intel_dp)
DRM_DEBUG_KMS("Failed to write EDID checksum\n");
  
  		test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;

-   intel_dp->compliance_test_data =
INTEL_DP_RESOLUTION_STANDARD;
+   intel_dp->compliance_test_data =
INTEL_DP_RESOLUTION_PREFERRED;

Is this used for anything else than logging?


}
  
  	/* Set test active flag here so userspace doesn't interrupt things */

@@ -4650,7 +4650,7 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
  
  	intel_dp->detect_done = false;
  
-	if (intel_connector->detect_edid)

+   if (intel_connector->detect_edid || intel_dp->compliance_test_active)

Should this check connector->edid_corrupt instead? I guess that would require
some logic to fallback to fail safe mode and bpc too.

I think Shubhangi had a patch for this same problem, but it also seems to create
a separate path for compliance.

Ander


For tests:
 *4.2.2.4 : Failed EDID read, I2C_NAK
 *4.2.2.5 : Failed EDID read, I2C_DEFER
 *4.2.2.6 : EDID corruption detected
when edid is detected to be corrupt, we need to fall back to failsafe mode.
This requires change for bpc and status to be connected which is being
performed in the patch: https://patchwork.freedesktop.org/patch/82566/
"drm/i915: Use fail safe mode when edid is corrupt"

Shubhangi



return connector_status_connected;
else
return connector_status_disconnected;


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

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Fixes to support the DP Compliance EDID tests.

[Shubhangi Shrivastava]

On Monday 23 May 2016 01:48 PM, Ander Conselvan De Oliveira wrote:

On Fri, 2016-04-29 at 18:28 -0700, Manasi Navare wrote:

This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte

Do you mean commit 559be30cb74d ("drm/i915: Implement the intel_dp_autotest_edid
function for DP EDID complaince tests")? Please see the link below on how to
refer to other commits in the commit message and how to add a Fixes: tag.

https://www.kernel.org/doc/Documentation/SubmittingPatches


Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
Intel connector status should be connected even if detect_edid is
NULL when compliance_test flag is set. This is required to handle
the corrupt EDID (CTS 4.2.2.6) or EDID Read Failure I2C NACK/I2C
DEFER (CTS 4.2.2.4 and 4.2.2.5) tests from CTS spec.

What exactly do those tests test? It sounds like this patch adds a separate code
path to implement the right behavior only when running the CTS. Shouldn't the
driver handle those failures during normal operation in the same way?


Signed-off-by: Manasi Navare 
---
  drivers/gpu/drm/i915/intel_dp.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0961f22..456fc17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4023,7 +4023,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct
intel_dp *intel_dp)
  
  static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)

  {
-   uint8_t test_result = DP_TEST_NAK;
+   uint8_t test_result = DP_TEST_ACK;
struct intel_connector *intel_connector = intel_dp-

attached_connector;

struct drm_connector *connector = _connector->base;
  
@@ -4058,7 +4058,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp

*intel_dp)
DRM_DEBUG_KMS("Failed to write EDID checksum\n");
  
  		test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;

-   intel_dp->compliance_test_data =
INTEL_DP_RESOLUTION_STANDARD;
+   intel_dp->compliance_test_data =
INTEL_DP_RESOLUTION_PREFERRED;

Is this used for anything else than logging?


}
  
  	/* Set test active flag here so userspace doesn't interrupt things */

@@ -4650,7 +4650,7 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
  
  	intel_dp->detect_done = false;
  
-	if (intel_connector->detect_edid)

+   if (intel_connector->detect_edid || intel_dp->compliance_test_active)

Should this check connector->edid_corrupt instead? I guess that would require
some logic to fallback to fail safe mode and bpc too.

I think Shubhangi had a patch for this same problem, but it also seems to create
a separate path for compliance.

Ander


For tests:
 *4.2.2.4 : Failed EDID read, I2C_NAK
 *4.2.2.5 : Failed EDID read, I2C_DEFER
 *4.2.2.6 : EDID corruption detected
when edid is detected to be corrupt, we need to fall back to failsafe mode.
This mode requires change for bpc and connected status which is being
performed in the patch: https://patchwork.freedesktop.org/patch/82566/
"drm/i915: Use fail safe mode when edid is corrupt"

Shubhangi




return connector_status_connected;
else
return connector_status_disconnected;


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

[Intel-gfx] [PATCH 2/2] drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume

[Imre Deak]

I noticed that during S4 resume BIOS incorrectly sets bits 18, 19 which
are reserved/MBZ and sets the decimal frequency fields to all 0xff in
the CDCLK register. The result is a hard lockup as display register
accesses are attempted later. Work around this by sanitizing the CDCLK
PLL/dividers the same way it's done on SKL.

While this is clearly a BIOS bug which should be fixed separately, it
doesn't hurt to check/sanitize this regardless.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c | 51 ++--
 1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b8e5995..479d2e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5412,11 +5412,58 @@ static void broxton_set_cdclk(struct drm_i915_private 
*dev_priv, int cdclk)
intel_update_cdclk(dev_priv->dev);
 }
 
+static void bxt_sanitize_cdclk(struct drm_i915_private *dev_priv)
+{
+   u32 cdctl, expected;
+
+   intel_update_cdclk(dev_priv->dev);
+
+   if (!dev_priv->cdclk_pll.vco ||
+   dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
+   goto sanitize;
+
+   /* DPLL okay; verify the cdclock
+*
+* Some BIOS versions leave an incorrect decimal frequency value and
+* set reserved MBZ bits in CDCLK_CTL at least during exiting from S4,
+* so sanitize this register.
+*/
+   cdctl = I915_READ(CDCLK_CTL);
+   /*
+* Let's ignore the pipe field, since BIOS could have configured the
+* dividers both synching to an active pipe, or asynchronously
+* (PIPE_NONE).
+*/
+   cdctl &= ~BXT_CDCLK_CD2X_PIPE_NONE;
+
+   expected = (cdctl & BXT_CDCLK_CD2X_DIV_SEL_MASK) |
+  skl_cdclk_decimal(dev_priv->cdclk_freq);
+   /*
+* Disable SSA Precharge when CD clock frequency < 500 MHz,
+* enable otherwise.
+*/
+   if (dev_priv->cdclk_freq >= 50)
+   expected |= BXT_CDCLK_SSA_PRECHARGE_ENABLE;
+
+   if (cdctl == expected)
+   /* All well; nothing to sanitize */
+   return;
+
+sanitize:
+   DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
+
+   /* force cdclk programming */
+   dev_priv->cdclk_freq = 0;
+
+   /* force full PLL disable + enable */
+   dev_priv->cdclk_pll.vco = -1;
+}
+
 void broxton_init_cdclk(struct drm_i915_private *dev_priv)
 {
-   intel_update_cdclk(dev_priv->dev);
+   bxt_sanitize_cdclk(dev_priv);
 
-   if (dev_priv->cdclk_pll.vco != 0)
+   if (dev_priv->cdclk_freq > 0 && dev_priv->cdclk_pll.vco > 0)
return;
 
/*
-- 
2.5.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/gen9: Assume CDCLK PLL is off if it's not locked

[Imre Deak]

If the CDCLK PLL isn't locked we can just assume that it's off resulting
in fully re-initializing both CDCLK PLL and CDCLK dividers. This way the
CDCLK PLL sanitization added in the following patch can be done on BXT
the same way as it's done on SKL.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c1e666b..b8e5995 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5461,14 +5461,14 @@ skl_dpll0_update(struct drm_i915_private *dev_priv)
u32 val;
 
dev_priv->cdclk_pll.ref = 24000;
+   dev_priv->cdclk_pll.vco = 0;
 
val = I915_READ(LCPLL1_CTL);
-   if ((val & LCPLL_PLL_ENABLE) == 0) {
-   dev_priv->cdclk_pll.vco = 0;
+   if ((val & LCPLL_PLL_ENABLE) == 0)
return;
-   }
 
-   WARN_ON((val & LCPLL_PLL_LOCK) == 0);
+   if (WARN_ON((val & LCPLL_PLL_LOCK) == 0))
+   return;
 
val = I915_READ(DPLL_CTRL1);
 
@@ -5690,9 +5690,10 @@ static void skl_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
if ((I915_READ(SWF_ILK(0x18)) & 0x00FF) == 0)
goto sanitize;
 
+   intel_update_cdclk(dev_priv->dev);
/* Is PLL enabled and locked ? */
-   if ((I915_READ(LCPLL1_CTL) & (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK)) !=
-   (LCPLL_PLL_ENABLE | LCPLL_PLL_LOCK))
+   if (!dev_priv->cdclk_pll.vco ||
+   dev_priv->cdclk_freq == dev_priv->cdclk_pll.ref)
goto sanitize;
 
if ((I915_READ(DPLL_CTRL1) & (DPLL_CTRL1_HDMI_MODE(SKL_DPLL0) |
@@ -5701,8 +5702,6 @@ static void skl_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
DPLL_CTRL1_OVERRIDE(SKL_DPLL0))
goto sanitize;
 
-   intel_update_cdclk(dev_priv->dev);
-
/* DPLL okay; verify the cdclock
 *
 * Noticed in some instances that the freq selection is correct but
@@ -6608,14 +6607,14 @@ static void bxt_de_pll_update(struct drm_i915_private 
*dev_priv)
u32 val;
 
dev_priv->cdclk_pll.ref = 19200;
+   dev_priv->cdclk_pll.vco = 0;
 
val = I915_READ(BXT_DE_PLL_ENABLE);
-   if ((val & BXT_DE_PLL_PLL_ENABLE) == 0) {
-   dev_priv->cdclk_pll.vco = 0;
+   if ((val & BXT_DE_PLL_PLL_ENABLE) == 0)
return;
-   }
 
-   WARN_ON((val & BXT_DE_PLL_LOCK) == 0);
+   if (WARN_ON((val & BXT_DE_PLL_LOCK) == 0))
+   return;
 
val = I915_READ(BXT_DE_PLL_CTL);
dev_priv->cdclk_pll.vco = (val & BXT_DE_PLL_RATIO_MASK) *
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Add support for mapping an object page by page

[Ankitprasad Sharma]

On Wed, 2016-04-20 at 13:04 +0100, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 04:47:28PM +0530, ankitprasad.r.sha...@intel.com 
> wrote:
> > From: Chris Wilson 
> > 
> > Introduced a new vm specfic callback insert_page() to program a single pte 
> > in
> > ggtt or ppgtt. This allows us to map a single page in to the mappable 
> > aperture
> > space. This can be iterated over to access the whole object by using space 
> > as
> > meagre as page size.
> > 
> > v2: Added low level rpm assertions to insert_page routines (Chris)
> > 
> > v3: Added POSTING_READ post register write (Tvrtko)
> > 
> > v4: Rebase (Ankit)
> > 
> > Signed-off-by: Chris Wilson 
> > Signed-off-by: Ankitprasad Sharma 
> > Reviewed-by: Tvrtko Ursulin 
> > ---
> >  drivers/char/agp/intel-gtt.c|  9 +
> >  drivers/gpu/drm/i915/i915_gem_gtt.c | 67 
> > +
> >  drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +++
> >  include/drm/intel-gtt.h |  3 ++
> >  4 files changed, 84 insertions(+)
> > 
> > diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> > index aef87fd..cea0ae3 100644
> > --- a/drivers/char/agp/intel-gtt.c
> > +++ b/drivers/char/agp/intel-gtt.c
> > @@ -840,6 +840,15 @@ static bool i830_check_flags(unsigned int flags)
> > return false;
> >  }
> >  
> > +void intel_gtt_insert_page(dma_addr_t addr,
> > +  unsigned int pg,
> > +  unsigned int flags)
> > +{
> > +   intel_private.driver->write_entry(addr, pg, flags);
> > +   wmb();
> > +}
> > +EXPORT_SYMBOL(intel_gtt_insert_page);
> > +
> >  void intel_gtt_insert_sg_entries(struct sg_table *st,
> >  unsigned int pg_start,
> >  unsigned int flags)
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 9f165fe..da1819d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2353,6 +2353,29 @@ static void gen8_set_pte(void __iomem *addr, 
> > gen8_pte_t pte)
> >  #endif
> >  }
> >  
> > +static void gen8_ggtt_insert_page(struct i915_address_space *vm,
> > + dma_addr_t addr,
> > + uint64_t offset,
> > + enum i915_cache_level level,
> > + u32 unused)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(vm->dev);
> > +   gen8_pte_t __iomem *pte =
> > +   (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
> > +   (offset >> PAGE_SHIFT);
> > +   int rpm_atomic_seq;
> > +
> > +   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
> > +
> > +   gen8_set_pte(pte, gen8_pte_encode(addr, level, true));
> > +   wmb();
> > +
> > +   I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> > +   POSTING_READ(GFX_FLSH_CNTL_GEN6);
> 
> Actually, we don't need these at all for the insert-page API (current
> users in pread/pwrite/reloc/gpu-error-capture) as they go through the
> GTT and not the GPU TLB. I would much rather we punt these to the caller
> with a vm->flush() which we can add later. When I say later, we already
> have the GUC pretending to be the GGTT and adding code where it doesn't
> belong...

I was trying to test the stolen memory patches on SKL with the removed
FLSH_CNTL write. Apparently, the insert_page routine does not seem to be
working. As I was verifying if the stolen-backed object is zeroed out
(using i915_gem_object_clear, which makes use of insert_page) on
creation but it failed (I was getting a garbage value instead of zeros).
And on adding this write it works as expected.

I think this write cannot be removed after all.

Thanks,
Ankit
> 
> All we need here is the wmb() to order the PTE write (and flush the WCB)
> with the use afterwards. The caller has to provide the wmb() to order
> its writes before a subsequent PTE change.
> 
> In a few patches time we can also kill the rpm_atomic asserts and the
> dev_priv local.
> -Chris
> 


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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Don't frob with RPS around GPU reset

[Chris Wilson]

On Tue, May 24, 2016 at 10:24:58AM +0200, Daniel Vetter wrote:
> On Mon, May 23, 2016 at 03:32:40PM +0100, Chris Wilson wrote:
> > On Mon, May 23, 2016 at 05:09:42PM +0300, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Based on my observations GPU reset doesn't clobber the RPS state, so
> > > frobbing with RPS around GPU reset seems rather pointless. Just get
> > > rid of it.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Testcase: igt/pm_rpm/reset ?
> 
> pm_rps_residency seem more appropriate. pm_rpm just outright yanks the
> power cable for the GT. Unfortunately those 2 tests aren't particularly
> nasty ...

Typo, I was looking at pm_rps since it has the reset test that should be
checking whether RPS works after hang/reset.
-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] Will Gen3/GMA950 benefit from tomic mode-setting ?

[Chris Wilson]

On Mon, May 23, 2016 at 04:34:47PM +0200, antistress wrote:
> Hi,
> 
> I own a netbook with a good old GMA 950 (Gen3 or Gen3.5 in Intel
> glossary) with few hardware decode capabilities (MPEG-2 motion
> compensation unless I am mistaken, which doesn't help for DivX
> movies for instance).
> 
> Will that graphical processor benefit from atomic mode-setting so
> that I can hope for better battery life while watching videos
> (dealing with YUV videos without RGB conversion is supposed to help)
> ?

No. The YUV planes are already exposed via Xv (usually adaptor=1) and
YUV->RGB conversion on the GPU (so that it works under a compositer
etc) on the other adaptor; both of them support scaling, but the hw
scaling for YUV planes uses a higher quality filter. Atomic modesestting
doesn't yet expose those planes.
-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] [RFC][PATCH 3/3] drm/i915: Make RPS enable immediate

[Daniel Vetter]

On Mon, May 23, 2016 at 05:09:43PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> On SNB (at least) it's dangeruopus to hang the GPU with an infinite
> batch buffer loop while RPS is disabled. The only thing that keeps
> the system going in such circumstances are the internal RPS timers,
> so we should never feed the GPU with RPS disabled unless we want to
> risk a total system hang.
> 
> Previously we didn't fully disable RPS, but that changes in
> commit 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> register")
> so we probably didn't see the problem so often previously. But
> even before that we were at the mercy of the BIOS for the initial
> RPS state, so if the BIOS didn't enable RPS a GPU hang immediately
> upon boot could have been fatal.
> 
> To avoid the problems let's just make the RPS enable immediate.
> This renders the delayed_resume_work useless actually. We could perhaps
> just move the ring freq table initialization to the work and do the
> other stull synchronously?
> 
> Fixes: 2030d684f7b3 ("drm/i915/bxt: Explicitly clear the Turbo control 
> register")
> Signed-off-by: Ville Syrjälä 
> ---
> This is more and RFC at this point. Perhaps we might want to keep the delayed
> work but just for the ring freq table update (which is the main reson this 
> whole
> thing exists in the first place). Another factor is that wait_for() is not
> exactly optiomal currently, so it makes the operation slower than it needs to
> be. Would need some hard numbers to see if it's worth keeping the delayed work
> or not I suppose.

Loading the ring freq tables takes forever, so definitely want to keep
that. I'd just split rps setup in two parts and push the schedule_work
down a bit. Long term we can go overboard with async (and maybey only
stall for all the GT setup in the very first batchbuffer).
-Daniel

> 
>  drivers/gpu/drm/i915/intel_pm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 817c84c22782..e65c5c2b9b4e 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6505,6 +6505,7 @@ void intel_enable_gt_powersave(struct drm_i915_private 
> *dev_priv)
>   if (schedule_delayed_work(_priv->rps.delayed_resume_work,
>  round_jiffies_up_relative(HZ)))
>   intel_runtime_pm_get_noresume(dev_priv);
> + flush_delayed_work(_priv->rps.delayed_resume_work);
>   }
>  }
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Don't frob with RPS around GPU reset

[Daniel Vetter]

On Mon, May 23, 2016 at 03:32:40PM +0100, Chris Wilson wrote:
> On Mon, May 23, 2016 at 05:09:42PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Based on my observations GPU reset doesn't clobber the RPS state, so
> > frobbing with RPS around GPU reset seems rather pointless. Just get
> > rid of it.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Testcase: igt/pm_rpm/reset ?

pm_rps_residency seem more appropriate. pm_rpm just outright yanks the
power cable for the GT. Unfortunately those 2 tests aren't particularly
nasty ...
-Daniel

> 
> Looks like that is the desired test.
> 
> Maybe make it basic and see what CI says :)
> 
> Actually it probably should be a basic test considering how often we
> hang.
> -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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Bump pin_count to UINT_MAX.

[Daniel Vetter]

On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
> With nonblocking unpin there can be many cursor pins before they're
> cleared by the next page flip.
> 
> Fix this by extending pin_count to the full 32-bit to prevent a
> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
> 
> Cc: Ville Syrjälä 
> Reported-by: Chris Wilson 
> Signed-off-by: Maarten Lankhorst 
> Fixes: a6747b7304a9 ("drm/i915: Make unpin async.")
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 62be77cac5cd..1d43cc290f71 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -218,8 +218,8 @@ struct i915_vma {
>*
>* In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
>* bits with absolutely no headroom. So use 4 bits. */
> - unsigned int pin_count:4;
> -#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 0xf
> + unsigned int pin_count;
> +#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT UINT_MAX

You need to read up on some of the history of this. The problem is that
some peeps have too many rt threads and managed to sufficiently stall our
unpin worker until we ran out of memory. Well, we would have if not for
this check here. The real fix should be to eventually stall for the unpin
workers to complete (like we do/did in the old pageflip code), or to have
an explicit (per-crtc probably) list of to-be-unpinned stuff, so that we
can process old unpins synchronously once they're completed. Just bumping
the limit so that no one notices that we leak pin counts like bad ain't a
fix ;-)
-Daniel

>  };
>  
>  struct i915_page_dma {
> -- 
> 2.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Show context objects in debugfs/i915_gem_objects

[Chris Wilson]

On Tue, May 24, 2016 at 10:13:24AM +0200, Daniel Vetter wrote:
> On Sun, May 22, 2016 at 02:02:32PM +0100, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Joonas Lahtinen 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 35 
> > +++
> >  1 file changed, 35 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 30cb26fe2fa9..3d14eb3215e1 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
> > print_file_stats(m, "[k]batch pool", stats);
> >  }
> >  
> > +static int per_file_ctx_stats(int id, void *ptr, void *data)
> > +{
> > +   struct i915_gem_context *ctx = ptr;
> > +   int n;
> > +
> > +   for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
> > +   if (ctx->engine[n].state)
> > +   per_file_stats(0, ctx->engine[n].state, data);
> > +   if (ctx->engine[n].ringbuf)
> > +   per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static void print_context_stats(struct seq_file *m,
> > +   struct drm_i915_private *dev_priv)
> > +{
> > +   struct file_stats stats;
> > +   struct drm_file *file;
> > +
> > +   memset(, 0, sizeof(stats));
> > +
> > +   if (dev_priv->kernel_context)
> > +   per_file_ctx_stats(0, dev_priv->kernel_context, );
> > +
> > +   list_for_each_entry(file, _priv->dev->filelist, lhead) {
> 
> dev->filelist has grown it's own lock now, dev->filelist_mutex. Should we
> have a drm_for_each_file macro which includes a helpful
> lockdep_assert_held?

I have a list_for_each_entry_check() in my tree, which allows you to
annotate which lock you are expected to be holding. (Because I wanted to
uplift the drm utilities.)

But iterating over filelist is not something I'd like to encourage.
drm_debug_for_each_file()
-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 i-g-t] tests/drv_module_reload_basic: Don't use rmmod exit code when reloading the module.

[Daniel Vetter]

On Tue, May 24, 2016 at 09:03:19AM +0100, Chris Wilson wrote:
> On Tue, May 24, 2016 at 09:55:26AM +0200, Daniel Vetter wrote:
> > On Mon, May 23, 2016 at 01:43:42PM +0300, Marius Vlad wrote:
> > > On Fri, May 20, 2016 at 05:23:56PM +0100, Chris Wilson wrote:
> > > > On Fri, May 20, 2016 at 07:00:18PM +0300, Imre Deak wrote:
> > > > > On pe, 2016-05-20 at 18:20 +0300, Marius Vlad wrote:
> > > > > > Either we return $IGT_EXIT_FAILURE or remove it entirely (like in
> > > > > > this
> > > > > > patch). If rmmod returns non-zero (i.e., Module: i915 is still in
> > > > > > use), reload
> > > > > > will bail with $IGT_EXIT_SKIP, making the check with lsmod useless.
> > > > > > Also use the return value in the fault-injection loop.
> > > > > > 
> > > > > > Signed-off-by: Marius Vlad 
> > > > > > ---
> > > > > >  tests/drv_module_reload_basic | 4 ++--
> > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/tests/drv_module_reload_basic
> > > > > > b/tests/drv_module_reload_basic
> > > > > > index 3bba796..3a8df33 100755
> > > > > > --- a/tests/drv_module_reload_basic
> > > > > > +++ b/tests/drv_module_reload_basic
> > > > > > @@ -30,7 +30,7 @@ function reload() {
> > > > > >  
> > > > > >     #ignore errors in ips - gen5 only
> > > > > >     rmmod intel_ips &> /dev/null
> > > > > > -   rmmod i915 || return $IGT_EXIT_SKIP
> > > > > > +   rmmod i915
> > > > > 
> > > > > Not sure what was the reason to bail out here, continuing seems like
> > > > > the correct thing to do.
> > > > 
> > > > If we can't unload, we can perform the modprobe testing. The system is
> > > > not in a state suitable for testing so skip or fail. If we are certain
> > > > that the rmmod failure is a bug, fail, if it merely something like the
> > > > system doesn't support module unloading, skip.
> > > I've seen this couple of times in the CI...and went mostly mostly
> > > unnoticed, wanted to make it hard-fail so it easy to spot when it happens
> > > again. Although it might be cases where the module is built-in this is
> > > not the case in CI.
> > 
> > The || SKIP was added in
> > 
> > commit f14d56c42d9e43df2790465aba6a2ea2593418fc
> > Author: Chris Wilson 
> > Date:   Fri Mar 11 21:25:48 2016 +
> > 
> > igt/drv_module_reload_basic: Rinse and repeat with addition module 
> > parameters
> > 
> > and apparently not intentionally.
> 
> It was, because the test wasn't behaving properly on my setup where I
> had disabled module unloading. If we can't unload the module, we have to
> SKIP the test.

I think a better check would be to lsmod | grep i915 and bail if that's
false. Yeah that'll still fall over if you have unloading disabled, but
either don't do that, or have some other check instead of rmmod i915 to
assess whether unloading works.

And please don't hide such changes in another commit without even
mentioning. i-g-t isn't free-for-all anymore, and if too much stuff slips
through then we'd have to lock down commit process a lot. I kinda don't
want that, since I still see plenty of benefits in making it simple to
create more tests.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ?==?utf-8?q? [RFC i-g-t 6/9] tests/gem_render_tiled_blits: Switched to new aliases of intel specific functions.

[Emil Velikov]

On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote: 
> From: Robert Foss 
> 
> Switched from drm_XXX aliases drm_intel_XXX aliases for symbols where that
> switch is possible.
> 
> Signed-off-by: Robert Foss 
> ---
>  tests/gem_render_tiled_blits.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
Looks like I've replied to 5/9 twice instead of here :-\

Reviewed-by: Emil Velikov 

-Emil

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

Re: [Intel-gfx] ?==?utf-8?q? [RFC i-g-t 5/9] tests/gem_ppgtt: Switched to new aliases of intel specific functions.

[Emil Velikov]

On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote: 
> From: Robert Foss 
> 
> Switched from drm_XXX aliases drm_intel_XXX aliases for symbols where that
> switch is possible.
> 
> Signed-off-by: Robert Foss 
> ---
>  tests/gem_ppgtt.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
Reviewed-by: Emil Velikov 

-Emil

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

Re: [Intel-gfx] ?==?utf-8?q? [RFC i-g-t 5/9] tests/gem_ppgtt: Switched to new aliases of intel specific functions.

[Emil Velikov]

On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote: 
> From: Robert Foss 
> 
> Switched from drm_XXX aliases drm_intel_XXX aliases for symbols where that
> switch is possible.
> 
> Signed-off-by: Robert Foss 
> ---
>  tests/gem_ppgtt.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
I could swear I've sent a similar looking patch... actually I have it only 
locally.

Reviewed-by: Emil Velikov 

-Emil


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

Re: [Intel-gfx] ?==?utf-8?q? [RFC i-g-t 8/9] lib: Replace intel specific header includes with intel_drm_stubs.h.

[Emil Velikov]

On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote: 
> From: Robert Foss 
> 
> Replace intel specific header includes with intel_drm_stubs.h.
> 
> The stubbed functions will all call igt_require(false) and cause a skip.
> 
> Signed-off-by: Robert Foss 
> ---
>  lib/drmtest.c   | 2 +-
>  lib/gpgpu_fill.c| 7 +++
>  lib/igt_aux.c   | 2 +-
>  lib/igt_aux.h   | 3 ++-
>  lib/igt_debugfs.c   | 4 ++--
>  lib/igt_draw.h  | 3 +--
>  lib/igt_fb.h| 3 ++-
>  lib/igt_kms.c   | 3 +--
>  lib/intel_batchbuffer.c | 4 
>  lib/intel_batchbuffer.h | 3 +--
>  lib/intel_chipset.c | 2 +-
>  lib/ioctl_wrappers.c| 1 -
>  lib/ioctl_wrappers.h| 4 ++--
>  lib/media_fill_gen7.c   | 3 +--
>  lib/media_fill_gen8.c   | 4 +---
>  lib/media_fill_gen8lp.c | 6 ++
>  lib/media_fill_gen9.c   | 4 +---
>  lib/media_spin.c| 2 --
>  lib/rendercopy_gen6.c   | 5 ++---
>  lib/rendercopy_gen7.c   | 4 +---
>  lib/rendercopy_gen8.c   | 4 +---
>  lib/rendercopy_gen9.c   | 5 +
>  lib/rendercopy_i830.c   | 5 +
>  lib/rendercopy_i915.c   | 9 +++--
>  24 files changed, 31 insertions(+), 61 deletions(-)
> 
This and next patch should be a simple sed job. Untangling the header 
inclusion(s) is a worthy goal imho, although it's not something that should be 
mixed in here.

The usual disclaimer... I've got little-to-no say when it comes to IGT so take 
all the above with a grain (truckload) of salt. That said, I'm fairly confident 
I haven't gone off the rocker this time and the reasoning is sound ;-)

Thanks
Emil

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

Re: [Intel-gfx] ?==?utf-8?q? [RFC i-g-t 7/9] lib/intel_drm_stubs: Add stubs for functionality from libdrm_intel.

[Emil Velikov]

On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote: 

> --- /dev/null
> +++ b/lib/intel_drm_stubs.c
Since this and the header file are stubs around intel_bufmgr, it might be 
better to call them intel_bufmgr_stubs.[ch]. In case "_stubs" in the name 
brings any confusion one could use _implementation/_internal and/or other.

> --- /dev/null
> +++ b/lib/intel_drm_stubs.h
> @@ -0,0 +1,999 @@
> +#ifndef INTEL_DRM_STUBS_H
> +#define INTEL_DRM_STUBS_H
> +
> +#include 
> +
> +#include "igt_core.h"
> +
Please don't. There is nothing here that requires either of these includes. 
As-is this makes the already convoluted header inclusion worse.

> +#ifdef HAVE_INTEL
> +#include 
> +#include 
> +#include 
> +
Similarly, please drop the drm headers. They are provided by libdrm itself (as 
opposed to libdrm_intel) and thus they should be available everywhere.

> +
> +#else
> +#define i915_execbuffer2_set_context_id(eb2, context) igt_require(false);
> +#define i915_execbuffer2_get_context_id(eb2) igt_require(false);
> +
Do we have (m)any test that don't any intel_bufmgr functionality and/or don't 
explicitly require intel drm device ? Afaict those will take precedense over 
the above two execbuf macros, thus one can omit the above.

For the rest of the patch you seems to be inlining i915_drm.h and 
intel_bufmgr.h which is a very bad idea imho. As-is it's fragile and hard to 
maintain.
If we drop the i915_drm.h changes, as suggested above, and copy/import the 
latter header as local_intel_bufmgr.h things will be better imho. It might be 
worth adding a note in the releasing document to sync the file with the latest 
libdrm_intel release.

Regards,
Emil

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

[Intel-gfx] Will Gen3/GMA950 benefit from tomic mode-setting ?

[antistress]

Hi,

I own a netbook with a good old GMA 950 (Gen3 or Gen3.5 in Intel 
glossary) with few hardware decode capabilities (MPEG-2 motion 
compensation unless I am mistaken, which doesn't help for DivX movies 
for instance).


Will that graphical processor benefit from atomic mode-setting so that I 
can hope for better battery life while watching videos (dealing with YUV 
videos without RGB conversion is supposed to help) ?


Thanks !

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

Re: [Intel-gfx] ?==?utf-8?q? ?==?utf-8?q? [RFC i-g-t 1/9]?==?utf-8?q? configure.ac: Test for libdrm_intel and build for it if present.

[Emil Velikov]

On Saturday, May 21, 2016 08:55 BST, Chris Wilson  
wrote: 
> On Fri, May 20, 2016 at 06:59:25PM -0400, robert.f...@collabora.com wrote:
> > From: Robert Foss 
> > 
> > Test for libdrm_intel and build for it if present.
> > Also expose the HAVE_INTEL #define to allow code to be conditionally
> > compiled.
> > 
> > Signed-off-by: Robert Foss 
> > ---
> >  configure.ac | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 0589782..b6fc168 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -100,7 +100,7 @@ if test "x$GCC" = "xyes"; then
> >  fi
> >  AC_SUBST(ASSEMBLER_WARN_CFLAGS)
> >  
> > -PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.64 libdrm])
> > +PKG_CHECK_MODULES(DRM, [libdrm])
> >  PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
> >  
> >  case "$target_cpu" in
> > @@ -150,6 +150,18 @@ PKG_CHECK_MODULES(GLIB, glib-2.0)
> >  # 
> > -
> >  #  Configuration options
> >  # 
> > -
> > +AC_ARG_ENABLE(intel, AS_HELP_STRING([--disable-intel],
> > + [Enable building of intel specific parts (default: auto)]),
> > + [INTEL=$enableval], [INTEL=auto])
> > +if test "x$INTEL" = xauto; then
> > +   PKG_CHECK_EXISTS([libdrm_intel >= 2.4.64], [INTEL=yes], [INTEL=no])
> > +fi
> > +if test "x$INTEL" = xyes; then
> > +   PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.64])
> > +   AC_DEFINE(HAVE_INTEL, 1, [Have intel support])
> > +fi
> > +AM_CONDITIONAL(HAVE_INTEL, [test "x$INTEL" = xyes])
> 
> HAVE_INTEL caused quite a bit of confusion when reading the later build
> patches.
> 
> Please use HAVE_LIBDRM_INTEL instead
As a counter argument, one could, should really, use --enable-intel to replace 
the 'x86' parts in commit bccc0ec6a3fdae880e14770c2ff5770fb86ea6fc. Perhaps 
HAVE_INTEL isn't that bad when we take that into consideration ?

Regards,
Emil

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

Re: [Intel-gfx] ?==?utf-8?q? [RFC i-g-t 2/9] benchmarks/Makefile: Don't build benchmarks that depend on libdrm_intel.

[Emil Velikov]

On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote: 
> From: Robert Foss 
> 
> Use the HAS_INTEL automake flag to avoid building benchmarks that won't
> compile unless libdrm_intel is available in the build system.
> 
> Signed-off-by: Robert Foss 
> ---
>  benchmarks/Makefile.sources | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/benchmarks/Makefile.sources b/benchmarks/Makefile.sources
> index 81607a5..26ee3ea 100644
> --- a/benchmarks/Makefile.sources
> +++ b/benchmarks/Makefile.sources
> @@ -1,10 +1,6 @@
>  benchmarksdir=$(libexecdir)/intel-gpu-tools/benchmarks
>  
>  benchmarks_PROGRAMS =\
> - intel_upload_blit_large \
> - intel_upload_blit_large_gtt \
> - intel_upload_blit_large_map \
> - intel_upload_blit_small \
>   gem_blt \
>   gem_create  \
>   gem_exec_ctx\
> @@ -16,6 +12,15 @@ benchmarks_PROGRAMS =  \
>   gem_prw \
>   gem_set_domain  \
>   gem_syslatency  \
> - gem_userptr_benchmark   \
>   kms_vblank  \
>   $(NULL)
> +
> +if HAVE_INTEL
> + benchmarks_PROGRAMS +=  \
> + intel_upload_blit_large \
> + intel_upload_blit_large_gtt \
> + intel_upload_blit_large_map \
> + intel_upload_blit_small \
> + gem_userptr_benchmark   \
> + $(NULL)
> +endif
Some suggestions:
 - Please don't use conditionals in the Makefile.sources - you'll break the 
other build (Android)
 - instead of ^^ use separate variable and combine them in the 
Makefile.am/Android.mk
 - Don't double-indent, don't think any other place does so.

Thanks
Emil

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

Re: [Intel-gfx] ?==?utf-8?q? [RFC i-g-t 3/9] tools/Makefile: Don't build tools that depend on libdrm_intel.

[Emil Velikov]

On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote: 
> From: Robert Foss 
> 
> Use the HAS_INTEL automake flag to avoid building tools that won't
> compile unless libdrm_intel is available in the build system.
> 
> Signed-off-by: Robert Foss 
> ---
>  tools/Makefile.sources | 50 
> +-
>  1 file changed, 29 insertions(+), 21 deletions(-)
> 
> diff --git a/tools/Makefile.sources b/tools/Makefile.sources
> index 5d5958d..c2dab8e 100644
> --- a/tools/Makefile.sources
> +++ b/tools/Makefile.sources
> @@ -1,42 +1,54 @@
> -noinst_PROGRAMS = \
> - hsw_compute_wrpll \
> - skl_compute_wrpll \
> - skl_ddb_allocation \
> +noinst_PROGRAMS =\
> + hsw_compute_wrpll   \
> + skl_compute_wrpll   \
> + skl_ddb_allocation  \
>   $(NULL)
>  
> -bin_PROGRAMS =   \
> +bin_PROGRAMS =   \
>   igt_stats   \
> - intel_audio_dump\
> + intel_audio_dump\
>   intel_reg   \
>   intel_backlight \
>   intel_bios_dumper   \
>   intel_bios_reader   \
>   intel_display_crc   \
>   intel_display_poller\
> - intel_dump_decode   \
> - intel_error_decode  \
>   intel_forcewaked\
>   intel_gpu_frequency \
> - intel_framebuffer_dump  \
>   intel_firmware_decode   \
> - intel_gpu_time  \
> - intel_gpu_top   \
> - intel_gtt   \
> + intel_gpu_time  \
> + intel_gpu_top   \
> + intel_gtt   \
>   intel_infoframes\
>   intel_l3_parity \
>   intel_lid   \
>   intel_opregion_decode   \
>   intel_panel_fitter  \
> - intel_perf_counters \
> - intel_reg_checker   \
> + intel_reg_checker   \
>   intel_residency \
> - intel_stepping  \
> + intel_stepping  \
Please don't mix functionality and cosmetic changes. Apply the whitespace 
polish as a separate patch ?

>   intel_watermark
>  
>  dist_bin_SCRIPTS = intel_gpu_abrt
>  
> -intel_dump_decode_SOURCES =  \
> - intel_dump_decode.c
> +if HAVE_INTEL
> + bin_PROGRAMS += \
> + intel_dump_decode   \
> + intel_error_decode  \
> + intel_framebuffer_dump  \
> + intel_perf_counters \
> + $(NULL)
> +
> + intel_dump_decode_SOURCES = \
> + intel_dump_decode.c \
> + $(NULL)
> +
> + intel_error_decode_SOURCES =\
> + intel_error_decode.c\
> + $(NULL)
> +
> + intel_error_decode_LDFLAGS = -lz
Apart from than my earlier comments, LDFLAGS variables should not live in this 
file. Please move it to Makefile.am.

Thanks
Emil

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

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Show context objects in debugfs/i915_gem_objects

[Daniel Vetter]

On Sun, May 22, 2016 at 02:02:32PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 30cb26fe2fa9..3d14eb3215e1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -417,6 +417,40 @@ static void print_batch_pool_stats(struct seq_file *m,
>   print_file_stats(m, "[k]batch pool", stats);
>  }
>  
> +static int per_file_ctx_stats(int id, void *ptr, void *data)
> +{
> + struct i915_gem_context *ctx = ptr;
> + int n;
> +
> + for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
> + if (ctx->engine[n].state)
> + per_file_stats(0, ctx->engine[n].state, data);
> + if (ctx->engine[n].ringbuf)
> + per_file_stats(0, ctx->engine[n].ringbuf->obj, data);
> + }
> +
> + return 0;
> +}
> +
> +static void print_context_stats(struct seq_file *m,
> + struct drm_i915_private *dev_priv)
> +{
> + struct file_stats stats;
> + struct drm_file *file;
> +
> + memset(, 0, sizeof(stats));
> +
> + if (dev_priv->kernel_context)
> + per_file_ctx_stats(0, dev_priv->kernel_context, );
> +
> + list_for_each_entry(file, _priv->dev->filelist, lhead) {

dev->filelist has grown it's own lock now, dev->filelist_mutex. Should we
have a drm_for_each_file macro which includes a helpful
lockdep_assert_held?

-Daniel

> + struct drm_i915_file_private *fpriv = file->driver_priv;
> + idr_for_each(>context_idr, per_file_ctx_stats, );
> + }
> +
> + print_file_stats(m, "[k]contexts", stats);
> +}
> +
>  #define count_vmas(list, member) do { \
>   list_for_each_entry(vma, list, member) { \
>   size += i915_gem_obj_total_ggtt_size(vma->obj); \
> @@ -521,6 +555,7 @@ static int i915_gem_object_info(struct seq_file *m, void* 
> data)
>  
>   seq_putc(m, '\n');
>   print_batch_pool_stats(m, dev_priv);
> + print_context_stats(m, dev_priv);
>  
>   mutex_unlock(>struct_mutex);
>  
> -- 
> 2.8.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Rename i915_gem_context_reference/unreference()

[Daniel Vetter]

On Mon, May 23, 2016 at 10:17:01AM +0100, Tvrtko Ursulin wrote:
> 
> On 22/05/16 14:02, Chris Wilson wrote:
> >As these are wrappers around kref_get/kref_put() it is preferable to
> >follow the naming convention and use the same verb get/put in our
> >wrapper names for manipulating a reference to the context.
> 
> Not so sure about this one. We got objects, framebuffers and requests using
> (un)reference naming so don't see that making contexts different is a good
> idea.

And drm_blob too. For core modeset stuff I think converting to _get/put
might be worth it, too, but needs 3-stage approach: Add new _get/put
funcs. 2) cocci-generated patches for each driver/file to convert over. 3)
drop _reference/unreference variants once no longer used.
-Daniel

> 
> Regards,
> 
> Tvrtko
> 
> 
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Joonas Lahtinen 
> >---
> >  drivers/gpu/drm/i915/i915_drv.h|  6 --
> >  drivers/gpu/drm/i915/i915_gem.c|  7 +++
> >  drivers/gpu/drm/i915/i915_gem_context.c| 22 ++
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  6 +++---
> >  drivers/gpu/drm/i915/intel_lrc.c   |  4 ++--
> >  5 files changed, 22 insertions(+), 23 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index e4e3614335ec..0a3442fcd93e 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -3435,12 +3435,14 @@ i915_gem_context_lookup(struct drm_i915_file_private 
> >*file_priv, u32 id)
> > return ctx;
> >  }
> >
> >-static inline void i915_gem_context_reference(struct i915_gem_context *ctx)
> >+static inline struct i915_gem_context *
> >+i915_gem_context_get(struct i915_gem_context *ctx)
> >  {
> > kref_get(>ref);
> >+return ctx;
> >  }
> >
> >-static inline void i915_gem_context_unreference(struct i915_gem_context 
> >*ctx)
> >+static inline void i915_gem_context_put(struct i915_gem_context *ctx)
> >  {
> > lockdep_assert_held(>i915->dev->struct_mutex);
> > kref_put(>ref, i915_gem_context_free);
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 728b66911840..d7ae030e5a0b 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -1418,7 +1418,7 @@ static void i915_gem_request_retire(struct 
> >drm_i915_gem_request *request)
> >request->engine);
> > }
> >
> >-i915_gem_context_unreference(request->ctx);
> >+i915_gem_context_put(request->ctx);
> > i915_gem_request_unreference(request);
> >  }
> >
> >@@ -2775,8 +2775,7 @@ __i915_gem_request_alloc(struct intel_engine_cs 
> >*engine,
> > req->i915 = dev_priv;
> > req->engine = engine;
> > req->reset_counter = reset_counter;
> >-req->ctx  = ctx;
> >-i915_gem_context_reference(req->ctx);
> >+req->ctx = i915_gem_context_get(ctx);
> >
> > /*
> >  * Reserve space in the ring buffer for all the commands required to
> >@@ -2798,7 +2797,7 @@ __i915_gem_request_alloc(struct intel_engine_cs 
> >*engine,
> > return 0;
> >
> >  err_ctx:
> >-i915_gem_context_unreference(ctx);
> >+i915_gem_context_put(ctx);
> >  err:
> > kmem_cache_free(dev_priv->requests, req);
> > return ret;
> >diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> >b/drivers/gpu/drm/i915/i915_gem_context.c
> >index aa329175f73a..a4c6377eea32 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_context.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >@@ -290,7 +290,7 @@ __create_hw_context(struct drm_device *dev,
> > return ctx;
> >
> >  err_out:
> >-i915_gem_context_unreference(ctx);
> >+i915_gem_context_put(ctx);
> > return ERR_PTR(ret);
> >  }
> >
> >@@ -351,7 +351,7 @@ err_unpin:
> > i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
> >  err_destroy:
> > idr_remove(_priv->context_idr, ctx->user_handle);
> >-i915_gem_context_unreference(ctx);
> >+i915_gem_context_put(ctx);
> > return ERR_PTR(ret);
> >  }
> >
> >@@ -363,7 +363,7 @@ static void i915_gem_context_unpin(struct 
> >i915_gem_context *ctx,
> > } else {
> > if (engine->id == RCS && ctx->legacy_hw_ctx.rcs_state)
> > 
> > i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
> >-i915_gem_context_unreference(ctx);
> >+i915_gem_context_put(ctx);
> > }
> >  }
> >
> >@@ -463,7 +463,7 @@ void i915_gem_context_fini(struct drm_device *dev)
> > if (dctx->legacy_hw_ctx.rcs_state)
> > i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
> >
> >-i915_gem_context_unreference(dctx);
> >+i915_gem_context_put(dctx);
> > dev_priv->kernel_context = NULL;
> >
> > ida_destroy(_priv->context_hw_ida);
> >@@ -473,7 +473,7 @@ static int context_idr_cleanup(int id, 

Re: [Intel-gfx] [PATCH i-g-t] tests/drv_module_reload_basic: Don't use rmmod exit code when reloading the module.

[Chris Wilson]

On Tue, May 24, 2016 at 09:03:19AM +0100, Chris Wilson wrote:
> On Tue, May 24, 2016 at 09:55:26AM +0200, Daniel Vetter wrote:
> > On Mon, May 23, 2016 at 01:43:42PM +0300, Marius Vlad wrote:
> > > On Fri, May 20, 2016 at 05:23:56PM +0100, Chris Wilson wrote:
> > > > On Fri, May 20, 2016 at 07:00:18PM +0300, Imre Deak wrote:
> > > > > On pe, 2016-05-20 at 18:20 +0300, Marius Vlad wrote:
> > > > > > Either we return $IGT_EXIT_FAILURE or remove it entirely (like in
> > > > > > this
> > > > > > patch). If rmmod returns non-zero (i.e., Module: i915 is still in
> > > > > > use), reload
> > > > > > will bail with $IGT_EXIT_SKIP, making the check with lsmod useless.
> > > > > > Also use the return value in the fault-injection loop.
> > > > > > 
> > > > > > Signed-off-by: Marius Vlad 
> > > > > > ---
> > > > > >  tests/drv_module_reload_basic | 4 ++--
> > > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/tests/drv_module_reload_basic
> > > > > > b/tests/drv_module_reload_basic
> > > > > > index 3bba796..3a8df33 100755
> > > > > > --- a/tests/drv_module_reload_basic
> > > > > > +++ b/tests/drv_module_reload_basic
> > > > > > @@ -30,7 +30,7 @@ function reload() {
> > > > > >  
> > > > > >     #ignore errors in ips - gen5 only
> > > > > >     rmmod intel_ips &> /dev/null
> > > > > > -   rmmod i915 || return $IGT_EXIT_SKIP
> > > > > > +   rmmod i915
> > > > > 
> > > > > Not sure what was the reason to bail out here, continuing seems like
> > > > > the correct thing to do.
> > > > 
> > > > If we can't unload, we can perform the modprobe testing. The system is
> > > > not in a state suitable for testing so skip or fail. If we are certain
> > > > that the rmmod failure is a bug, fail, if it merely something like the
> > > > system doesn't support module unloading, skip.
> > > I've seen this couple of times in the CI...and went mostly mostly
> > > unnoticed, wanted to make it hard-fail so it easy to spot when it happens
> > > again. Although it might be cases where the module is built-in this is
> > > not the case in CI.
> > 
> > The || SKIP was added in
> > 
> > commit f14d56c42d9e43df2790465aba6a2ea2593418fc
> > Author: Chris Wilson 
> > Date:   Fri Mar 11 21:25:48 2016 +
> > 
> > igt/drv_module_reload_basic: Rinse and repeat with addition module 
> > parameters
> > 
> > and apparently not intentionally.
> 
> It was, because the test wasn't behaving properly on my setup where I
> had disabled module unloading. If we can't unload the module, we have to
> SKIP the test.

The problem is that we actually have the test split up incorrectly.
Instead of doing a

preparation phase;

for_each_subtest
load;
check;

unload
check;

restoration

we have 

for_each_subtest;
unload
load
check

and so we are doingthe tail of the first test in the second.
-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] [RFC i-g-t 8/9] lib: Replace intel specific header includes with intel_drm_stubs.h.

[Daniel Vetter]

On Fri, May 20, 2016 at 06:59:32PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> Replace intel specific header includes with intel_drm_stubs.h.
> 
> The stubbed functions will all call igt_require(false) and cause a skip.
> 
> Signed-off-by: Robert Foss 

Do we need this sed job really? I kinda hoped we could have a dummy header
somewhere, like lib/stubs/drm/i915_drm.h and similar (instead of your
intel_drm_stubs.h), and then add lib/stubs/ to the include path when
!HAVE_LIBDRM_INTEL? That way 0 changes to tests/lib itself should be
needed.
-Daniel

> ---
>  lib/drmtest.c   | 2 +-
>  lib/gpgpu_fill.c| 7 +++
>  lib/igt_aux.c   | 2 +-
>  lib/igt_aux.h   | 3 ++-
>  lib/igt_debugfs.c   | 4 ++--
>  lib/igt_draw.h  | 3 +--
>  lib/igt_fb.h| 3 ++-
>  lib/igt_kms.c   | 3 +--
>  lib/intel_batchbuffer.c | 4 
>  lib/intel_batchbuffer.h | 3 +--
>  lib/intel_chipset.c | 2 +-
>  lib/ioctl_wrappers.c| 1 -
>  lib/ioctl_wrappers.h| 4 ++--
>  lib/media_fill_gen7.c   | 3 +--
>  lib/media_fill_gen8.c   | 4 +---
>  lib/media_fill_gen8lp.c | 6 ++
>  lib/media_fill_gen9.c   | 4 +---
>  lib/media_spin.c| 2 --
>  lib/rendercopy_gen6.c   | 5 ++---
>  lib/rendercopy_gen7.c   | 4 +---
>  lib/rendercopy_gen8.c   | 4 +---
>  lib/rendercopy_gen9.c   | 5 +
>  lib/rendercopy_i830.c   | 5 +
>  lib/rendercopy_i915.c   | 9 +++--
>  24 files changed, 31 insertions(+), 61 deletions(-)
> 
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 7d6b74a..f043607 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -48,13 +48,13 @@
>  #include 
>  
>  #include "drmtest.h"
> -#include "i915_drm.h"
>  #include "intel_chipset.h"
>  #include "intel_io.h"
>  #include "igt_gt.h"
>  #include "igt_debugfs.h"
>  #include "version.h"
>  #include "config.h"
> +#include "intel_drm_stubs.h"
>  #include "intel_reg.h"
>  #include "ioctl_wrappers.h"
>  
> diff --git a/lib/gpgpu_fill.c b/lib/gpgpu_fill.c
> index 4d98643..62b1161 100644
> --- a/lib/gpgpu_fill.c
> +++ b/lib/gpgpu_fill.c
> @@ -25,15 +25,14 @@
>   *  Dominik Zeromski 
>   */
>  
> -#include 
> -#include 
>  
> -#include "intel_reg.h"
>  #include "drmtest.h"
> -#include "intel_batchbuffer.h"
>  #include "gen7_media.h"
>  #include "gen8_media.h"
>  #include "gpgpu_fill.h"
> +#include "intel_batchbuffer.h"
> +#include "intel_drm_stubs.h"
> +#include "intel_reg.h"
>  
>  /* shaders/gpgpu/gpgpu_fill.gxa */
>  static const uint32_t gen7_gpgpu_kernel[][4] = {
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index fe18365..772c902 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -52,12 +52,12 @@
>  #include 
>  
>  #include "drmtest.h"
> -#include "i915_drm.h"
>  #include "intel_chipset.h"
>  #include "igt_aux.h"
>  #include "igt_debugfs.h"
>  #include "igt_gt.h"
>  #include "config.h"
> +#include "intel_drm_stubs.h"
>  #include "intel_reg.h"
>  #include "ioctl_wrappers.h"
>  #include "igt_kms.h"
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index f66de72..c66121b 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -28,10 +28,11 @@
>  #ifndef IGT_AUX_H
>  #define IGT_AUX_H
>  
> -#include 
>  #include 
>  #include 
>  
> +#include "intel_drm_stubs.h"
> +
>  extern drm_intel_bo **trash_bos;
>  extern int num_trash_bos;
>  
> diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> index a32ed78..d9f371f 100644
> --- a/lib/igt_debugfs.c
> +++ b/lib/igt_debugfs.c
> @@ -32,12 +32,12 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "drmtest.h"
> +#include "intel_drm_stubs.h"
>  #include "igt_aux.h"
> -#include "igt_kms.h"
>  #include "igt_debugfs.h"
> +#include "igt_kms.h"
>  
>  /**
>   * SECTION:igt_debugfs
> diff --git a/lib/igt_draw.h b/lib/igt_draw.h
> index b030131..c0e95ca 100644
> --- a/lib/igt_draw.h
> +++ b/lib/igt_draw.h
> @@ -25,9 +25,8 @@
>  #ifndef __IGT_DRAW_H__
>  #define __IGT_DRAW_H__
>  
> -#include 
>  #include "igt_fb.h"
> -
> +#include "intel_drm_stubs.h"
>  /**
>   * igt_draw_method:
>   * @IGT_DRAW_MMAP_CPU: draw using a CPU mmap.
> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> index ce2cc0f..82dbacb 100644
> --- a/lib/igt_fb.h
> +++ b/lib/igt_fb.h
> @@ -38,10 +38,11 @@ typedef struct _cairo cairo_t;
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> -#include 
> +#include "intel_drm_stubs.h"
>  
>  /* helpers to create nice-looking framebuffers */
>  struct igt_fb {
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index f85be1e..7afee53 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -41,12 +41,11 @@
>  #include 
>  #include 
>  
> -#include 
> -
>  #include "drmtest.h"
>  #include "igt_kms.h"
>  #include "igt_aux.h"
>  #include "intel_chipset.h"
> +#include "intel_drm_stubs.h"
>  #include "igt_debugfs.h"
>  
>  /* list of connectors that need resetting on exit */
> diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
> 

Re: [Intel-gfx] [RFC i-g-t 7/9] lib/intel_drm_stubs: Add stubs for functionality from libdrm_intel.

[Daniel Vetter]

On Fri, May 20, 2016 at 06:59:31PM -0400, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> This patch provides stubs for functionality otherwise provided by 
> libdrm_intel.
> 
> The stubbed functions all fail with a call to igt_require(false).
> Defines and enums have been copied from libdrm_intel.

For prettiness mayb igt_require_f(false, "Not compiled with libdrm_intel
support\n"); or something similar.
-Daniel

> 
> Due to the stubbed tests failing with an igt_require() call, these stubs are
> not well suited for non-tests, since tools/benchmarks/etc 'skipping'
> execution is unhelpful.
> 
> Signed-off-by: Robert Foss 
> ---
>  lib/Makefile.sources  |   2 +
>  lib/intel_drm_stubs.c | 258 +
>  lib/intel_drm_stubs.h | 999 
> ++
>  3 files changed, 1259 insertions(+)
>  create mode 100644 lib/intel_drm_stubs.c
>  create mode 100644 lib/intel_drm_stubs.h
> 
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 1316fd2..c0f9f6d 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -21,6 +21,8 @@ libintel_tools_la_SOURCES = \
>   intel_batchbuffer.c \
>   intel_batchbuffer.h \
>   intel_chipset.h \
> + intel_drm_stubs.c   \
> + intel_drm_stubs.h   \
>   intel_os.c  \
>   intel_io.h  \
>   intel_mmio.c\
> diff --git a/lib/intel_drm_stubs.c b/lib/intel_drm_stubs.c
> new file mode 100644
> index 000..d46a9b3
> --- /dev/null
> +++ b/lib/intel_drm_stubs.c
> @@ -0,0 +1,258 @@
> +#ifndef HAVE_INTEL
> +
> +#include "intel_drm_stubs.h"
> +
> +drm_intel_bufmgr *drm_intel_bufmgr_gem_init(int fd, int batch_size)
> +{
> + igt_require(false);
> + return (drm_intel_bufmgr *) NULL;
> +}
> +
> +void drm_intel_bo_unreference(drm_intel_bo *bo)
> +{
> + igt_require(false);
> +}
> +
> +drm_intel_bo *drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
> +  unsigned long size, unsigned int alignment)
> +{
> + igt_require(false);
> + return (drm_intel_bo *) NULL;
> +}
> +
> +int drm_intel_bo_subdata(drm_intel_bo *bo, unsigned long offset,
> +  unsigned long size, const void *data)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +int drm_intel_gem_bo_context_exec(drm_intel_bo *bo, drm_intel_context *ctx,
> +   int used, unsigned int flags)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +int drm_intel_bo_emit_reloc(drm_intel_bo *bo, uint32_t offset,
> + drm_intel_bo *target_bo, uint32_t target_offset,
> + uint32_t read_domains, uint32_t write_domain)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +int drm_intel_bo_emit_reloc_fence(drm_intel_bo *bo, uint32_t offset,
> +   drm_intel_bo *target_bo,
> +   uint32_t target_offset,
> +   uint32_t read_domains, uint32_t write_domain)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +int drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t * tiling_mode,
> + uint32_t * swizzle_mode)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +int drm_intel_bo_mrb_exec(drm_intel_bo *bo, int used,
> + struct drm_clip_rect *cliprects, int num_cliprects, int 
> DR4,
> + unsigned int flags)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +void drm_intel_bufmgr_gem_set_aub_annotations(drm_intel_bo *bo,
> +  drm_intel_aub_annotation *annotations,
> +  unsigned count)
> +{
> + igt_require(false);
> +}
> +
> +void drm_intel_bufmgr_gem_enable_reuse(drm_intel_bufmgr *bufmgr)
> +{
> + igt_require(false);
> +}
> +
> +int drm_intel_bo_exec(drm_intel_bo *bo, int used,
> +   struct drm_clip_rect *cliprects, int num_cliprects, 
> int DR4)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +void drm_intel_bufmgr_destroy(drm_intel_bufmgr *bufmgr)
> +{
> + igt_require(false);
> +}
> +
> +void drm_intel_bo_wait_rendering(drm_intel_bo *bo)
> +{
> + igt_require(false);
> +}
> +
> +int drm_intel_bo_get_subdata(drm_intel_bo *bo, unsigned long offset,
> +  unsigned long size, void *data)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +int drm_intel_bo_map(drm_intel_bo *bo, int write_enable)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
> +{
> + igt_require(false);
> + return 0;
> +}
> +
> +void drm_intel_bufmgr_gem_enable_fenced_relocs(drm_intel_bufmgr *bufmgr)
> +{
> + igt_require(false);
> +}
> +
> +int drm_intel_bo_unmap(drm_intel_bo *bo)
> +{
> +

Re: [Intel-gfx] [RFC i-g-t 6/9] tests/gem_render_tiled_blits: Switched to new aliases of intel specific functions.

[Daniel Vetter]

On Mon, May 23, 2016 at 03:39:12PM +0100, Emil Velikov wrote:
> On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote:
> > From: Robert Foss 
> >
> > Switched from drm_XXX aliases drm_intel_XXX aliases for symbols where that
> > switch is possible.
> >
> > Signed-off-by: Robert Foss 
> > ---
> >  tests/gem_render_tiled_blits.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> Looks like I've replied to 5/9 twice instead of here :-\
> 
> Reviewed-by: Emil Velikov 

Also applied, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/drv_module_reload_basic: Don't use rmmod exit code when reloading the module.

[Chris Wilson]

On Tue, May 24, 2016 at 09:55:26AM +0200, Daniel Vetter wrote:
> On Mon, May 23, 2016 at 01:43:42PM +0300, Marius Vlad wrote:
> > On Fri, May 20, 2016 at 05:23:56PM +0100, Chris Wilson wrote:
> > > On Fri, May 20, 2016 at 07:00:18PM +0300, Imre Deak wrote:
> > > > On pe, 2016-05-20 at 18:20 +0300, Marius Vlad wrote:
> > > > > Either we return $IGT_EXIT_FAILURE or remove it entirely (like in
> > > > > this
> > > > > patch). If rmmod returns non-zero (i.e., Module: i915 is still in
> > > > > use), reload
> > > > > will bail with $IGT_EXIT_SKIP, making the check with lsmod useless.
> > > > > Also use the return value in the fault-injection loop.
> > > > > 
> > > > > Signed-off-by: Marius Vlad 
> > > > > ---
> > > > >  tests/drv_module_reload_basic | 4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/tests/drv_module_reload_basic
> > > > > b/tests/drv_module_reload_basic
> > > > > index 3bba796..3a8df33 100755
> > > > > --- a/tests/drv_module_reload_basic
> > > > > +++ b/tests/drv_module_reload_basic
> > > > > @@ -30,7 +30,7 @@ function reload() {
> > > > >  
> > > > >   #ignore errors in ips - gen5 only
> > > > >   rmmod intel_ips &> /dev/null
> > > > > - rmmod i915 || return $IGT_EXIT_SKIP
> > > > > + rmmod i915
> > > > 
> > > > Not sure what was the reason to bail out here, continuing seems like
> > > > the correct thing to do.
> > > 
> > > If we can't unload, we can perform the modprobe testing. The system is
> > > not in a state suitable for testing so skip or fail. If we are certain
> > > that the rmmod failure is a bug, fail, if it merely something like the
> > > system doesn't support module unloading, skip.
> > I've seen this couple of times in the CI...and went mostly mostly
> > unnoticed, wanted to make it hard-fail so it easy to spot when it happens
> > again. Although it might be cases where the module is built-in this is
> > not the case in CI.
> 
> The || SKIP was added in
> 
> commit f14d56c42d9e43df2790465aba6a2ea2593418fc
> Author: Chris Wilson 
> Date:   Fri Mar 11 21:25:48 2016 +
> 
> igt/drv_module_reload_basic: Rinse and repeat with addition module 
> parameters
> 
> and apparently not intentionally.

It was, because the test wasn't behaving properly on my setup where I
had disabled module unloading. If we can't unload the module, we have to
SKIP the test.
-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] [RFC i-g-t 5/9] tests/gem_ppgtt: Switched to new aliases of intel specific functions.

[Daniel Vetter]

On Mon, May 23, 2016 at 03:15:26PM +0100, Emil Velikov wrote:
> On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote:
> > From: Robert Foss 
> >
> > Switched from drm_XXX aliases drm_intel_XXX aliases for symbols where that
> > switch is possible.
> >
> > Signed-off-by: Robert Foss 
> > ---
> >  tests/gem_ppgtt.c | 18 +-
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> >
> Reviewed-by: Emil Velikov 

Applied, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC i-g-t 2/9] benchmarks/Makefile: Don't build benchmarks that depend on libdrm_intel.

[Daniel Vetter]

On Mon, May 23, 2016 at 03:04:16PM +0100, Emil Velikov wrote:
> On Friday, May 20, 2016 23:59 BST, robert.f...@collabora.com wrote:
> > From: Robert Foss 
> >
> > Use the HAS_INTEL automake flag to avoid building benchmarks that won't
> > compile unless libdrm_intel is available in the build system.
> >
> > Signed-off-by: Robert Foss 
> > ---
> >  benchmarks/Makefile.sources | 15 ++-
> >  1 file changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/benchmarks/Makefile.sources b/benchmarks/Makefile.sources
> > index 81607a5..26ee3ea 100644
> > --- a/benchmarks/Makefile.sources
> > +++ b/benchmarks/Makefile.sources
> > @@ -1,10 +1,6 @@
> >  benchmarksdir=$(libexecdir)/intel-gpu-tools/benchmarks
> >
> >  benchmarks_PROGRAMS =  \
> > -   intel_upload_blit_large \
> > -   intel_upload_blit_large_gtt \
> > -   intel_upload_blit_large_map \
> > -   intel_upload_blit_small \
> > gem_blt \
> > gem_create  \
> > gem_exec_ctx\
> > @@ -16,6 +12,15 @@ benchmarks_PROGRAMS =\
> > gem_prw \
> > gem_set_domain  \
> > gem_syslatency  \
> > -   gem_userptr_benchmark   \
> > kms_vblank  \
> > $(NULL)
> > +
> > +if HAVE_INTEL
> > +   benchmarks_PROGRAMS +=  \
> > +   intel_upload_blit_large \
> > +   intel_upload_blit_large_gtt \
> > +   intel_upload_blit_large_map \
> > +   intel_upload_blit_small \
> > +   gem_userptr_benchmark   \
> > +   $(NULL)
> > +endif
> Some suggestions:
>  - Please don't use conditionals in the Makefile.sources - you'll break the 
> other build (Android)
>  - instead of ^^ use separate variable and combine them in the 
> Makefile.am/Android.mk
>  - Don't double-indent, don't think any other place does so.

Atm the other build is Intel-only, so I don't think it's that bad really -
if we add a #define HAVE_INTEL there before including Makefile.sources (or
whatever the make magic for this is). If someone wants to build igt on
other Android machines that needs some extensions, but hey not my problem
when Android wants to reinvent half of autoconf ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: warning for Add USB typeC based DP support for BXT platform (rev8)

[Patchwork]

== Series Details ==

Series: Add USB typeC based DP support for BXT platform (rev8)
URL   : https://patchwork.freedesktop.org/series/1731/
State : warning

== Summary ==

Series 1731v8 Add USB typeC based DP support for BXT platform
http://patchwork.freedesktop.org/api/1.0/series/1731/revisions/8/mbox

Test gem_busy:
Subgroup basic-bsd:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Subgroup basic-parallel-vebox:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_exec_basic:
Subgroup gtt-vebox:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test gem_ringfill:
Subgroup basic-default-interruptible:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test gem_storedw_loop:
Subgroup basic-default:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup basic-plain-flip:
pass   -> SKIP   (ro-bdw-i7-5557U)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> SKIP   (ro-bdw-i7-5557U)
Test kms_pipe_crc_basic:
Subgroup bad-pipe:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)
Subgroup hang-read-crc-pipe-a:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup hang-read-crc-pipe-b:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup hang-read-crc-pipe-c:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup nonblocking-crc-pipe-a:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup nonblocking-crc-pipe-b:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup nonblocking-crc-pipe-c:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup read-crc-pipe-a:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup read-crc-pipe-b:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup read-crc-pipe-c:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup suspend-read-crc-pipe-b:
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (ro-bdw-i7-5557U)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> DMESG-WARN (ro-skl-i7-6700hq)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-WARN (ro-skl-i7-6700hq)
pass   -> SKIP   (ro-bdw-i7-5557U)
Subgroup basic-rte:
pass   -> SKIP   (ro-bdw-i7-5557U)
Test pm_rps:
Subgroup basic-api:
dmesg-warn -> PASS   (ro-skl-i7-6700hq)

ro-bdw-i5-5250u  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5557U  total:209  pass:172  dwarn:0   dfail:0   fail:0   skip:37 
ro-bdw-i7-5600u  total:209  pass:180  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:209  pass:168  dwarn:0   dfail:0   fail:2   skip:39 
ro-hsw-i3-4010u  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:209  pass:186  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk1-i5-650   total:204  pass:146  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:209  pass:177  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:209  pass:181  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl-i7-6700hq total:204  pass:176  dwarn:7   dfail:0   fail:0   skip:21 
ro-snb-i7-2620M  total:209  pass:170  dwarn:0   dfail:0   fail:1   skip:38 
ro-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_986/

8621fb5 drm-intel-nightly: 2016y-05m-23d-18h-18m-33s UTC integration manifest
70401b1 drm/i915/dp: Enable Upfront link training for typeC 

Re: [Intel-gfx] [PATCH i-g-t] tests/drv_module_reload_basic: Don't use rmmod exit code when reloading the module.

[Daniel Vetter]

On Mon, May 23, 2016 at 01:43:42PM +0300, Marius Vlad wrote:
> On Fri, May 20, 2016 at 05:23:56PM +0100, Chris Wilson wrote:
> > On Fri, May 20, 2016 at 07:00:18PM +0300, Imre Deak wrote:
> > > On pe, 2016-05-20 at 18:20 +0300, Marius Vlad wrote:
> > > > Either we return $IGT_EXIT_FAILURE or remove it entirely (like in
> > > > this
> > > > patch). If rmmod returns non-zero (i.e., Module: i915 is still in
> > > > use), reload
> > > > will bail with $IGT_EXIT_SKIP, making the check with lsmod useless.
> > > > Also use the return value in the fault-injection loop.
> > > > 
> > > > Signed-off-by: Marius Vlad 
> > > > ---
> > > >  tests/drv_module_reload_basic | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/tests/drv_module_reload_basic
> > > > b/tests/drv_module_reload_basic
> > > > index 3bba796..3a8df33 100755
> > > > --- a/tests/drv_module_reload_basic
> > > > +++ b/tests/drv_module_reload_basic
> > > > @@ -30,7 +30,7 @@ function reload() {
> > > >  
> > > >     #ignore errors in ips - gen5 only
> > > >     rmmod intel_ips &> /dev/null
> > > > -   rmmod i915 || return $IGT_EXIT_SKIP
> > > > +   rmmod i915
> > > 
> > > Not sure what was the reason to bail out here, continuing seems like
> > > the correct thing to do.
> > 
> > If we can't unload, we can perform the modprobe testing. The system is
> > not in a state suitable for testing so skip or fail. If we are certain
> > that the rmmod failure is a bug, fail, if it merely something like the
> > system doesn't support module unloading, skip.
> I've seen this couple of times in the CI...and went mostly mostly
> unnoticed, wanted to make it hard-fail so it easy to spot when it happens
> again. Although it might be cases where the module is built-in this is
> not the case in CI.

The || SKIP was added in

commit f14d56c42d9e43df2790465aba6a2ea2593418fc
Author: Chris Wilson 
Date:   Fri Mar 11 21:25:48 2016 +

igt/drv_module_reload_basic: Rinse and repeat with addition module 
parameters

and apparently not intentionally. Please cite that commit using Fixes: and
ack on your patch from my side.
-Daniel

> 
> > 
> > Continuing on after failure to unload is not a good idea.
> > -Chris
> > 
> > -- 
> > Chris Wilson, Intel Open Source Technology Centre



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove ddi_pll_sel from intel_crtc_state

[R, Durgadoss]

> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Tuesday, May 24, 2016 1:03 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: R, Durgadoss ; Conselvan De Oliveira, Ander
> 
> Subject: [PATCH v2] drm/i915: Remove ddi_pll_sel from intel_crtc_state
> 
> The value of ddi_pll_sel is derived from the selection of shared dpll,
> so just calculate the final value when necessary.
> 
> v2: Actually remove it from crtc state and delete remaining usages. (CI)
> 

Looks good to me,

Reviewed-by: Durgadoss R 

Thanks,
Durga

> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 45 ++--
> ---
>  drivers/gpu/drm/i915/intel_display.c  | 43 +++--
>  drivers/gpu/drm/i915/intel_dp_mst.c   |  3 ++-
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 27 -
>  drivers/gpu/drm/i915/intel_drv.h  |  8 +--
>  5 files changed, 45 insertions(+), 81 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1cbdd66..2ee5c4c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -531,6 +531,27 @@ static void intel_wait_ddi_buf_idle(struct
> drm_i915_private *dev_priv,
>   DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n",
> port_name(port));
>  }
> 
> +static uint32_t hsw_pll_to_ddi_pll_sel(struct intel_shared_dpll *pll)
> +{
> + switch (pll->id) {
> + case DPLL_ID_WRPLL1:
> + return PORT_CLK_SEL_WRPLL1;
> + case DPLL_ID_WRPLL2:
> + return PORT_CLK_SEL_WRPLL2;
> + case DPLL_ID_SPLL:
> + return PORT_CLK_SEL_SPLL;
> + case DPLL_ID_LCPLL_810:
> + return PORT_CLK_SEL_LCPLL_810;
> + case DPLL_ID_LCPLL_1350:
> + return PORT_CLK_SEL_LCPLL_1350;
> + case DPLL_ID_LCPLL_2700:
> + return PORT_CLK_SEL_LCPLL_2700;
> + default:
> + MISSING_CASE(pll->id);
> + return PORT_CLK_SEL_NONE;
> + }
> +}
> +
>  /* Starting with Haswell, different DDI ports can work in FDI mode for
>   * connection to the PCH-located connectors. For this, it is necessary to 
> train
>   * both the DDI port and PCH receiver for the desired DDI buffer settings.
> @@ -546,7 +567,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_encoder *encoder;
> - u32 temp, i, rx_ctl_val;
> + u32 temp, i, rx_ctl_val, ddi_pll_sel;
> 
>   for_each_encoder_on_crtc(dev, crtc, encoder) {
>   WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG);
> @@ -577,8 +598,9 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
> 
>   /* Configure Port Clock Select */
> - I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc->config-
> >ddi_pll_sel);
> - WARN_ON(intel_crtc->config->ddi_pll_sel != PORT_CLK_SEL_SPLL);
> + ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config-
> >shared_dpll);
> + I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
> + WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
> 
>   /* Start the training iterating through available voltages and
> emphasis,
>* testing each value twice. */
> @@ -855,7 +877,7 @@ static void skl_ddi_clock_get(struct intel_encoder
> *encoder,
>   int link_clock = 0;
>   uint32_t dpll_ctl1, dpll;
> 
> - dpll = pipe_config->ddi_pll_sel;
> + dpll = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
> 
>   dpll_ctl1 = I915_READ(DPLL_CTRL1);
> 
> @@ -903,7 +925,7 @@ static void hsw_ddi_clock_get(struct intel_encoder
> *encoder,
>   int link_clock = 0;
>   u32 val, pll;
> 
> - val = pipe_config->ddi_pll_sel;
> + val = hsw_pll_to_ddi_pll_sel(pipe_config->shared_dpll);
>   switch (val & PORT_CLK_SEL_MASK) {
>   case PORT_CLK_SEL_LCPLL_810:
>   link_clock = 81000;
> @@ -1568,13 +1590,15 @@ uint32_t ddi_signal_levels(struct intel_dp
> *intel_dp)
>  }
> 
>  void intel_ddi_clk_select(struct intel_encoder *encoder,
> -   const struct intel_crtc_state *pipe_config)
> +   struct intel_shared_dpll *pll)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
> 
> + if (WARN_ON(!pll))
> + return;
> +
>   if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> - uint32_t dpll = pipe_config->ddi_pll_sel;
>   uint32_t val;
> 
>   /* DDI -> PLL mapping  */
> @@ -1582,14 +1606,13 @@ void intel_ddi_clk_select(struct intel_encoder
> *encoder,
> 
>   val &= ~(DPLL_CTRL2_DDI_CLK_OFF(port) |
>   

Re: [Intel-gfx] [PATCHv6 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[Ander Conselvan De Oliveira]

On Fri, 2016-05-20 at 14:29 +0530, Durgadoss R wrote:
> To support USB type C alternate DP mode, the display driver needs to
> know the number of lanes required by the DP panel as well as number
> of lanes that can be supported by the type-C cable. Sometimes, the
> type-C cable may limit the bandwidth even if Panel can support
> more lanes. To address these scenarios, the display driver will
> start link training with max lanes, and if that fails, the driver
> falls back to x2 lanes; and repeats this procedure for all
> bandwidth/lane configurations.
> 
> * Since link training is done before modeset only the port
>   (and not pipe/planes) and its associated PLLs are enabled.
> * On DP hotplug: Directly start link training on the DP encoder.
> * On Connected boot scenarios: When booted with an LFP and a DP,
>   sometimes BIOS brings up DP. In these cases, we disable the
>   crtc and then do upfront link training; and bring it back up.
> * All local changes made for upfront link training are reset
>   to their previous values once it is done; so that the
>   subsequent modeset is not aware of these changes.
> 
> Changes since v5:
> * Moved retry logic in upfront to intel_dp.c so that it
>   can be used for all platforms.
> Changes since v4:
> * Removed usage of crtc_state in upfront link training;
>   Hence no need to find free crtc to do upfront now.
> * Re-enable crtc if it was disabled for upfront.
> * Use separate variables to track max lane count
>   and link rate found by upfront, without modifying
>   the original DPCD read from panel.
> Changes since v3:
> * Fixed a return value on BXT check
> * Reworked on top of bxt_ddi_pll_select split from Ander
> * Renamed from ddi_upfront to bxt_upfront since the
>   upfront logic includes BXT specific functions for now.
> Changes since v2:
> * Rebased on top of latest dpll_mgr.c code and
>   latest HPD related clean ups.
> * Corrected return values from upfront (Ander)
> * Corrected atomic locking for upfront in intel_dp.c (Ville)
> Changes since v1:
> *  all pll related functions inside ddi.c
> 
> Signed-off-by: Durgadoss R 

I have one comment below, but this is

Reviewed-by: Ander Conselvan de Oliveira  ---
>  drivers/gpu/drm/i915/intel_ddi.c |  45 ++
>  drivers/gpu/drm/i915/intel_dp.c  | 179 +-
> -
>  drivers/gpu/drm/i915/intel_drv.h |   8 ++
>  3 files changed, 226 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 7e6331a..8d224bf 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2330,6 +2330,51 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port
> *intel_dig_port)
>   return connector;
>  }
>  
> +bool intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
> + int clock, uint8_t lane_count)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> + struct intel_encoder *encoder = connector->encoder;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_shared_dpll *pll;
> + struct intel_shared_dpll_config tmp_pll_config;
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + enum intel_dpll_id dpll_id = (enum intel_dpll_id)dig_port->port;
> +
> + /*
> +  * FIXME: Works only for BXT.
> +  * Select the required PLL. This works for platforms where
> +  * there is no shared DPLL.
> +  */
> + pll = _priv->shared_dplls[dpll_id];
> + if (WARN_ON(pll->active_mask)) {
> + DRM_ERROR("Shared DPLL already in use. active_mask:%x\n",
> pll->active_mask);
> + return false;
> + }
> +
> + tmp_pll_config = pll->config;
> +
> + if (!bxt_ddi_dp_set_dpll_hw_state(clock, >config.hw_state)) {
> + DRM_ERROR("Could not setup DPLL\n");
> + pll->config = tmp_pll_config;
> + return false;
> + }
> +
> + /* Enable PLL followed by port */
> + pll->funcs.enable(dev_priv, pll);
> + intel_ddi_pre_enable_dp(encoder, clock, lane_count, pll);
> +
> + DRM_DEBUG_KMS("Upfront link train %s: link_clock:%d lanes:%d\n",
> + intel_dp->train_set_valid ? "Passed" : "Failed", clock, lane_count);
> +
> + /* Disable port followed by PLL for next retry/clean up */
> + intel_ddi_post_disable(encoder);
> + pll->funcs.disable(dev_priv, pll);
> +
> + pll->config = tmp_pll_config;
> + return intel_dp->train_set_valid;
> +}
> +
>  void intel_ddi_init(struct drm_device *dev, enum port port)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 95ba5aa..6ecaa30 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ 

[Intel-gfx] [PATCH v2] drm/i915: Remove ddi_pll_sel from intel_crtc_state

[Ander Conselvan de Oliveira]

The value of ddi_pll_sel is derived from the selection of shared dpll,
so just calculate the final value when necessary.

v2: Actually remove it from crtc state and delete remaining usages. (CI)

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_ddi.c  | 45 ++-
 drivers/gpu/drm/i915/intel_display.c  | 43 +++--
 drivers/gpu/drm/i915/intel_dp_mst.c   |  3 ++-
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 27 -
 drivers/gpu/drm/i915/intel_drv.h  |  8 +--
 5 files changed, 45 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1cbdd66..2ee5c4c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -531,6 +531,27 @@ static void intel_wait_ddi_buf_idle(struct 
drm_i915_private *dev_priv,
DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n", port_name(port));
 }
 
+static uint32_t hsw_pll_to_ddi_pll_sel(struct intel_shared_dpll *pll)
+{
+   switch (pll->id) {
+   case DPLL_ID_WRPLL1:
+   return PORT_CLK_SEL_WRPLL1;
+   case DPLL_ID_WRPLL2:
+   return PORT_CLK_SEL_WRPLL2;
+   case DPLL_ID_SPLL:
+   return PORT_CLK_SEL_SPLL;
+   case DPLL_ID_LCPLL_810:
+   return PORT_CLK_SEL_LCPLL_810;
+   case DPLL_ID_LCPLL_1350:
+   return PORT_CLK_SEL_LCPLL_1350;
+   case DPLL_ID_LCPLL_2700:
+   return PORT_CLK_SEL_LCPLL_2700;
+   default:
+   MISSING_CASE(pll->id);
+   return PORT_CLK_SEL_NONE;
+   }
+}
+
 /* Starting with Haswell, different DDI ports can work in FDI mode for
  * connection to the PCH-located connectors. For this, it is necessary to train
  * both the DDI port and PCH receiver for the desired DDI buffer settings.
@@ -546,7 +567,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *encoder;
-   u32 temp, i, rx_ctl_val;
+   u32 temp, i, rx_ctl_val, ddi_pll_sel;
 
for_each_encoder_on_crtc(dev, crtc, encoder) {
WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG);
@@ -577,8 +598,9 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   I915_WRITE(PORT_CLK_SEL(PORT_E), intel_crtc->config->ddi_pll_sel);
-   WARN_ON(intel_crtc->config->ddi_pll_sel != PORT_CLK_SEL_SPLL);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config->shared_dpll);
+   I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
+   WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
/* Start the training iterating through available voltages and emphasis,
 * testing each value twice. */
@@ -855,7 +877,7 @@ static void skl_ddi_clock_get(struct intel_encoder *encoder,
int link_clock = 0;
uint32_t dpll_ctl1, dpll;
 
-   dpll = pipe_config->ddi_pll_sel;
+   dpll = intel_get_shared_dpll_id(dev_priv, pipe_config->shared_dpll);
 
dpll_ctl1 = I915_READ(DPLL_CTRL1);
 
@@ -903,7 +925,7 @@ static void hsw_ddi_clock_get(struct intel_encoder *encoder,
int link_clock = 0;
u32 val, pll;
 
-   val = pipe_config->ddi_pll_sel;
+   val = hsw_pll_to_ddi_pll_sel(pipe_config->shared_dpll);
switch (val & PORT_CLK_SEL_MASK) {
case PORT_CLK_SEL_LCPLL_810:
link_clock = 81000;
@@ -1568,13 +1590,15 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
 }
 
 void intel_ddi_clk_select(struct intel_encoder *encoder,
- const struct intel_crtc_state *pipe_config)
+ struct intel_shared_dpll *pll)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
 
+   if (WARN_ON(!pll))
+   return;
+
if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
-   uint32_t dpll = pipe_config->ddi_pll_sel;
uint32_t val;
 
/* DDI -> PLL mapping  */
@@ -1582,14 +1606,13 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
 
val &= ~(DPLL_CTRL2_DDI_CLK_OFF(port) |
DPLL_CTRL2_DDI_CLK_SEL_MASK(port));
-   val |= (DPLL_CTRL2_DDI_CLK_SEL(dpll, port) |
+   val |= (DPLL_CTRL2_DDI_CLK_SEL(pll->id, port) |
DPLL_CTRL2_DDI_SEL_OVERRIDE(port));
 
I915_WRITE(DPLL_CTRL2, val);
 
} else if (INTEL_INFO(dev_priv)->gen < 9) {
-   WARN_ON(pipe_config->ddi_pll_sel == PORT_CLK_SEL_NONE);
-   I915_WRITE(PORT_CLK_SEL(port), pipe_config->ddi_pll_sel);
+   I915_WRITE(PORT_CLK_SEL(port), hsw_pll_to_ddi_pll_sel(pll));