Re: [Intel-gfx] [PATCH 15/16] drm/i915: Mechanism to forward clock monotonic time in perf samples

[sourab gupta]

On Sat, 2016-04-23 at 01:19 +0530, Chris Wilson wrote:
> On Fri, Apr 22, 2016 at 05:04:04PM +0530, sourab.gu...@intel.com wrote:
> > +static u64 get_current_gpu_ts(struct drm_i915_private *dev_priv)
> > +{
> > +   return  ((u64)I915_READ(GT_TIMESTAMP_COUNT_UDW) << 32) |
> > +   I915_READ(GT_TIMESTAMP_COUNT);
> 
> return I915_READ64_2x32(GT_TIMESTAMP_COUNT, GT_TIMESTAMP_COUNT_UDW);

Thanks for pointing out. Will make this change.

> 
> > +static void i915_perf_get_clock(struct drm_i915_private *dev_priv,
> > +   u64 *clk_mono, u64 *gpu_time, u64 *gpu_ts)
> > +{
> > +   u64 remainder, ts_interval = NSEC_PER_SEC;
> > +   u32 gpu_freq = dev_priv->perf.timestamp_frequency;
> > +   unsigned long flags;
> > +
> > +   local_irq_save(flags);
> > +   *clk_mono = ktime_get_mono_fast_ns();
> > +   *gpu_ts = get_current_gpu_ts(dev_priv);
> > +   local_irq_restore(flags);
> > +
> > +   remainder = do_div(ts_interval, gpu_freq);
> > +   remainder *= *gpu_ts;
> > +   do_div(remainder, gpu_freq);
> > +
> > +   *gpu_time = ((*gpu_ts) * ts_interval) + remainder;
> > +}
> > +
> > +static void i915_perf_clock_sync_work(struct work_struct *work)
> > +{
> 
> Have you looked at cross-timestamps?

I was looking at the cross-timestamp patch set
(https://lkml.org/lkml/2016/1/4/541), but I'm not entirely sure the
cross timestamp stuff is solving the same problem. The cross timestamp
stuff is trying to "synchronously capture system/device timestamp(s)".
While here, we have a log of many recorded device timestamps and want to
correlate all of those with system timestamp (_CLOCK_MONOTONOC for now).
As we aren't reading system/device timestamps together for all
timestamps we have, our problem is more about deriving an accurate idea
of timestamp frequency to improve the accuracy when correlating between
the synchronization points. Maybe the cross timestamp stuff will help to
periodically read tightly correlated timestamp pairs synchronously which
can be used as basis for correlating the logged timestamps based on our
derived timestamp frequency. This idea can be evaluated once the cross
timestamp patches land in kernel.


> -Chris
> 


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

[Intel-gfx] [Regression report] Weekly regression report WW19

[jairo . daniel . miramontes . caton]

WW19 Regression report.

 There was no new regressions last week.

 Previous Regressions

+---+---+++
| BugId | Summary   | Created on | Bisect |
+---+---+++
| 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | Yes|
| 84855 | [ILK regression]igt kms_rotation_crc/sprite-r | 2014-10-10 | No |
| 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | No |
| 87725 | [BDW Bisected] OglBatch7 performance reduced  | 2014-12-26 | Yes|
| 87726 | [BDW Bisected] OglDrvCtx performance reduced  | 2014-12-26 | Yes|
| 88439 | [BDW Bisected]igt/gem_reloc_vs_gpu/forked-fau | 2015-01-15 | Yes|
| 89334 | [945 regression] 4.0-rc1 kernel GPU hang:  ec | 2015-02-26 | No |
| 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | No |
| 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | No |
| 89728 | [HSW/BDW/BYT bisected] igt / pm_rps / reset f | 2015-03-23 | Yes|
| 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | Yes|
| 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | Yes|
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | Yes|
| 90368 | [SNB BSW SKL BXT KBL] bisected igt/kms_3d has | 2015-05-08 | Yes|
| 90732 | [BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forked | 2015-05-29 | Yes|
| 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 | No |
| 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | Yes|
| 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | No |
| 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 | No |
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 | Yes|
| 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-ex | 2015-10-16 | No |
| 92575 | [4.2 regression] Massive graphics corruption  | 2015-10-21 | No |
| 92972 | Black screen on Intel NUC hardware (i915) pos | 2015-11-16 | No |
| 93122 | [SNB BAT IGT regression] pm_rpm started skipp | 2015-11-26 | No |
| 93263 | 945GM regression since 4.3| 2015-12-05 | No |
| 93393 | Regression for Skylake modesetting in kernel  | 2015-12-16 | No |
| 93802 | [IVB bisected] switching to tty1 causes fifo  | 2016-01-20 | Yes|
| 93971 | video framerate performance regression with U | 2016-02-02 | No |
| 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 | No |
| 94416 | [KBL HSW] [Regression] kms_frontbuffer_tracki | 2016-03-06 | No |
| 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 | No |
| 94585 | [BXT-P/KBL/BSW] igt/gem_reset_stats regressio | 2016-03-17 | No |
| 94587 | [KBL] igt/kms_plane/plane-panning-bottom-righ | 2016-03-17 | No |
| 94588 | [KBL/BSW/BXT] igt/gem_reloc_overflow regressi | 2016-03-17 | No |
| 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 | No |
| 94676 | Possible kernel regression for gen3 and earli | 2016-03-23 | No |
| 94748 | Black screen on Skylake (mouse position relat | 2016-03-29 | No |
| 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | No |
| 95172 | [KBL] [regression] pm_rpm / debugfs-read fail | 2016-04-27 | No |
| 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 | No |
+---+---+++
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

Refcounting is hard, so here's a quick pull request with the one-liner to
fix up i915. Otherwise just a few other small things I picked up. Plus the
regression fix from Marten for rmfb behaviour that lingered around forever
since no testers. Feel free to cherry-pick that over to drm-fixes, but
given that there's not many who seemed to have cared, meh.

Cheers, Daniel


The following changes since commit 0552f7651bc233e5407ab06ba97a9d7c25e19580:

  drm/i915/mst: use reference counted connectors. (v3) (2016-05-05 12:52:07 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-05-08

for you to fetch changes up to 8863dc7f5642737e49ff681cbb842d2c614bdcf4:

  drm/i915: Correctly refcount connectors in hw state readou (2016-05-06 
16:09:12 +0200)


Daniel Vetter (3):
  drm: Fix up markup fumble
  drm: Add gpu.tmpl docbook to MAINTAINERS entry
  drm/i915: Correctly refcount connectors in hw state readou

Lyude (1):
  drm/fb_helper: Fix a few typos

Maarten Lankhorst (1):
  drm/core: Do not preserve framebuffer on rmfb, v4.

Thierry Reding (1):
  drm/panel: Flesh out kerneldoc

 Documentation/DocBook/gpu.tmpl   | 12 --
 MAINTAINERS  |  1 +
 drivers/gpu/drm/drm_crtc.c   | 63 
 drivers/gpu/drm/drm_fb_helper.c  |  6 +--
 drivers/gpu/drm/drm_panel.c  | 61 +++
 drivers/gpu/drm/i915/intel_display.c |  5 +++
 include/drm/drm_modeset_helper_vtables.h |  2 +-
 include/drm/drm_panel.h  | 59 ++
 8 files changed, 195 insertions(+), 14 deletions(-)

-- 
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] Updated drm-intel-testing

[Daniel Vetter]

Hi all,

New -testing cycle with cool stuff:
- refactor stolen quirks to share code between early quirks and i915 (Joonas)
- refactor gem BO/vma funcstion (Tvrtko)
- backlight over DPCD support (Yetunde Abedisi)
- more dsi panel sequence support (Jani)
- lots of refactoring around handling iomaps, vma, ring access and related
  topics culmulating in removing the duplicated request tracking in the execlist
  code (Chris & Tvrtko) includes a small patch for core iomapping code
- hw state readout for bxt dsi (Ramalingam C)
- cdclk cleanups (Ville)
- dedupe chv pll code a bit (Ander)
- enable semaphores on gen8+ for legacy submission, to be able to have a direct
  comparison against execlist on the same platform (Chris) Not meant to be used
  for anything else but performance tuning
- lvds border bit hw state checker fix (Jani)
- rpm vs. shrinker/oom-notifier fixes (Praveen Paneri)
- l3 tuning (Imre)
- revert mst dp audio, it's totally non-functional and crash-y (Lyude)
- first official dmc for kbl (Rodrigo)
- and tons of small things all over as usual

Happy testing!

Cheers, 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 3/3] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)

[Daniel Vetter]

On Tue, Apr 26, 2016 at 12:25:18PM +0100, Yetunde Adebisi wrote:
> This patch adds support for eDP backlight control using DPCD registers to
> backlight hooks in intel_panel.
> 
> It checks for backlight control over AUX channel capability and sets up
> function pointers to get and set the backlight brightness level if
> supported.
> 
> v2: Moved backlight functions from intel_dp.c into a new file
> intel_dp_aux_backlight.c. Also moved reading of eDP display control
> registers to intel_dp_get_dpcd
> 
> v3: Correct some formatting mistakes
> 
> v4: Updated to use AUX backlight control if PWM control is not possible
>   (Jani)
> v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
> v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
> backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
> v7: Add enable_dpcd_backlight module parameter.
> v8: Rebase onto latest drm-intel-nightly branch
> v9: Remove references to intel_dp_dpcd_read_wake
> Split addition edp_dpcd variable into a separate patch
> 
> Cc: Bob Paauwe 
> Cc: Jani Nikula 
> Signed-off-by: Yetunde Adebisi 

Just a quick comment since I'm typing the regular changelog summaries: I
think the backlight driver in here would have been real nice as a generic
thing on top of the dp aux library. But ok if the next person gets to do
that, too ;-)
-Daniel

> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/i915_params.c|   4 +
>  drivers/gpu/drm/i915/i915_params.h|   1 +
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 
> ++
>  drivers/gpu/drm/i915/intel_drv.h  |   3 +
>  drivers/gpu/drm/i915/intel_panel.c|   4 +
>  6 files changed, 186 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0b88ba0..723c502 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -81,6 +81,7 @@ i915-y += dvo_ch7017.o \
> dvo_tfp410.o \
> intel_crt.o \
> intel_ddi.o \
> +   intel_dp_aux_backlight.o \
> intel_dp_link_training.o \
> intel_dp_mst.o \
> intel_dp.o \
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 1779f02..383c076 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -58,6 +58,7 @@ struct i915_params i915 __read_mostly = {
>   .guc_log_level = -1,
>   .enable_dp_mst = true,
>   .inject_load_failure = 0,
> + .enable_dpcd_backlight = false,
>  };
>  
>  module_param_named(modeset, i915.modeset, int, 0400);
> @@ -210,3 +211,6 @@ MODULE_PARM_DESC(enable_dp_mst,
>  module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, 
> uint, 0400);
>  MODULE_PARM_DESC(inject_load_failure,
>   "Force an error after a number of failure check points (0:disabled 
> (default), N:force failure at the Nth failure check point)");
> +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
> 0600);
> +MODULE_PARM_DESC(enable_dpcd_backlight,
> + "Enable support for DPCD backlight control (default:false)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 02bc278..65e73dd 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -61,6 +61,7 @@ struct i915_params {
>   bool verbose_state_checks;
>   bool nuclear_pageflip;
>   bool enable_dp_mst;
> + bool enable_dpcd_backlight;
>  };
>  
>  extern struct i915_params i915 __read_mostly;
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> new file mode 100644
> index 000..984fb0d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -0,0 +1,173 @@
> +/*
> + * Copyright © 2015 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 

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

[Chris Wilson]

On Sat, May 07, 2016 at 09:18:24PM +0300, Ville Syrjälä wrote:
> On Fri, May 06, 2016 at 09:22:49PM +0100, Chris Wilson wrote:
> > On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrj...@linux.intel.com 
> > wrote:
> > > @@ -730,9 +730,14 @@ int i915_suspend_switcheroo(struct drm_device *dev, 
> > > pm_message_t state)
> > >  static int i915_drm_resume(struct drm_device *dev)
> > >  {
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > > + int ret;
> > >  
> > >   disable_rpm_wakeref_asserts(dev_priv);
> > >  
> > > + ret = i915_ggtt_enable_hw(dev);
> > > + if (ret)
> > > + DRM_ERROR("failed to re-enable GGTT\n");
> > 
> > Would it not be fatal for resume as well? Failure means we can't use the
> > GGTT, so all subsequent writes will be going into a random address.
> 
> Yeah, I assume things would blow up. The question is however, what can
> we do in this case? We'd basically have to shut the entire driver down.
> I don't think we have a way to do that?

No, I was naively thinking that erring out during resume would magically
shut the driver down.
-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] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

[Stefan Richter]

On May 08 Stefan Richter wrote:
> On May 06 Daniel Vetter wrote:
> > On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote:
> [...]
> > > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s)  
> > 
> > This one failed in both runs. Can you please retest with just that using
> > 
> > # kms_frontbuffer_tracking --run-subtest 
> > fbc-1p-primscrn-spr-indfb-fullscreen
> > 
> > Also please boot with drm.debug=0xe and grab the full dmesg of just that
> > single subtest. There's definitely something going wrong here.
> 
> I performed this test with
>   - plain v4.6-rc6,
>   - v4.6-rc6 patched with drm-intel-nightly (2016y-05m-06d-14h-29m-58s).
> 
> On v4.6-rc6, the test failed thus:
[...]
> On v4.6-rc6 plus drm-intel-nightly, the test apparently passed:
[...]
> I will send the kernel messages from each of these two tests in a reply to
> intel-gfx@lists.freedesktop.org only.

Attached are the kernel logs from the two test runs.
Do you need to see the kernel messages from before the test started too?
-- 
Stefan Richter
-==- -=-= -=---
http://arcgraph.de/sr/
[0.00] Linux version 4.6.0-rc6 (stefan@kant) (gcc version 5.3.0 (Gentoo 
5.3.0 p1.0, pie-0.6.5) ) #2 SMP PREEMPT Fri May 6 00:25:46 CEST 2016
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.6.0-rc6 root=/dev/sda4 ro 
rootflags=subvol=@ drm.debug=0xe
# ...
[  358.434393] kms_frontbuffer_tracking: executing
[  358.436374] [drm:i915_gem_open] 
[  358.436656] [drm:i915_gem_open] 
[  358.436669] [drm:drm_mode_getresources] CRTC[3] CONNECTORS[6] ENCODERS[10]
[  358.436672] [drm:drm_mode_getresources] [CRTC:26:crtc-0]
[  358.436673] [drm:drm_mode_getresources] [CRTC:30:crtc-1]
[  358.436674] [drm:drm_mode_getresources] [CRTC:34:crtc-2]
[  358.436675] [drm:drm_mode_getresources] [ENCODER:37:DAC-37]
[  358.436676] [drm:drm_mode_getresources] [ENCODER:38:TMDS-38]
[  358.436677] [drm:drm_mode_getresources] [ENCODER:40:DP MST-40]
[  358.436678] [drm:drm_mode_getresources] [ENCODER:41:DP MST-41]
[  358.436678] [drm:drm_mode_getresources] [ENCODER:42:DP MST-42]
[  358.436679] [drm:drm_mode_getresources] [ENCODER:47:TMDS-47]
[  358.436680] [drm:drm_mode_getresources] [ENCODER:49:TMDS-49]
[  358.436681] [drm:drm_mode_getresources] [ENCODER:51:DP MST-51]
[  358.436682] [drm:drm_mode_getresources] [ENCODER:52:DP MST-52]
[  358.436682] [drm:drm_mode_getresources] [ENCODER:53:DP MST-53]
[  358.436683] [drm:drm_mode_getresources] [CONNECTOR:36:VGA-1]
[  358.436684] [drm:drm_mode_getresources] [CONNECTOR:39:DP-1]
[  358.436685] [drm:drm_mode_getresources] [CONNECTOR:45:HDMI-A-1]
[  358.436686] [drm:drm_mode_getresources] [CONNECTOR:48:HDMI-A-2]
[  358.436687] [drm:drm_mode_getresources] [CONNECTOR:50:DP-2]
[  358.436687] [drm:drm_mode_getresources] [CONNECTOR:54:HDMI-A-3]
[  358.436688] [drm:drm_mode_getresources] CRTC[3] CONNECTORS[6] ENCODERS[10]
[  358.436693] [drm:drm_mode_getconnector] [CONNECTOR:36:?]
[  358.436695] [drm:drm_mode_getconnector] [CONNECTOR:36:?]
[  358.436697] [drm:drm_mode_getconnector] [CONNECTOR:39:?]
[  358.436701] [drm:drm_mode_getconnector] [CONNECTOR:39:?]
[  358.436709] [drm:drm_mode_getconnector] [CONNECTOR:45:?]
[  358.436710] [drm:drm_mode_getconnector] [CONNECTOR:45:?]
[  358.436712] [drm:drm_mode_getconnector] [CONNECTOR:48:?]
[  358.436713] [drm:drm_mode_getconnector] [CONNECTOR:48:?]
[  358.436715] [drm:drm_mode_getconnector] [CONNECTOR:50:?]
[  358.436716] [drm:drm_mode_getconnector] [CONNECTOR:50:?]
[  358.436718] [drm:drm_mode_getconnector] [CONNECTOR:54:?]
[  358.436719] [drm:drm_mode_getconnector] [CONNECTOR:54:?]
[  358.436821] [drm:drm_mode_addfb2] [FB:79]
[  358.436829] [drm:drm_mode_addfb2] [FB:80]
[  358.436840] [drm:drm_mode_addfb2] [FB:81]
[  358.436851] [drm:drm_mode_addfb2] [FB:82]
[  358.436863] [drm:drm_mode_addfb2] [FB:83]
[  358.437186] kms_frontbuffer_tracking: starting subtest 
fbc-1p-primscrn-spr-indfb-fullscreen
[  358.437214] Setting dangerous option i915.enable_fbc - tainting kernel
[  358.437223] Setting dangerous option i915.enable_psr - tainting kernel
[  358.437228] [drm:drm_mode_setcrtc] [CRTC:26:crtc-0]
[  358.437245] [drm:hsw_audio_codec_disable] Disable audio codec on pipe A
[  358.437249] [drm:intel_disable_pipe] disabling pipe A
[  358.451607] [drm:__intel_fbc_disable] Disabling FBC on pipe A
[  358.451617] [drm:intel_power_well_disable] disabling always-on
[  358.451618] [drm:intel_power_well_disable] disabling display
[  358.451620] [drm:hsw_set_power_well] Requesting to disable the power well
[  358.451624] [drm:intel_connector_check_state] [CONNECTOR:39:DP-1]
[  358.451625] [drm:intel_power_well_enable] enabling always-on
[  358.451626] [drm:intel_power_well_disable] disabling always-on
[  358.451628] [drm:check_encoder_state] [ENCODER:37:DAC-37]
[  358.451629] [drm:intel_power_well_enable] enabling always-on
[  358.451630] [drm:intel_power_well_disable] disabling always-on
[  358.451631] [drm:check_encoder_state] [ENCODER:38:TMDS-38]
[  358.451632] 

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

[Stefan Richter]

On May 06 Daniel Vetter wrote:
> On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote:
[...]
> > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s)  
> 
> This one failed in both runs. Can you please retest with just that using
> 
> # kms_frontbuffer_tracking --run-subtest fbc-1p-primscrn-spr-indfb-fullscreen
> 
> Also please boot with drm.debug=0xe and grab the full dmesg of just that
> single subtest. There's definitely something going wrong here.

I performed this test with
  - plain v4.6-rc6,
  - v4.6-rc6 patched with drm-intel-nightly (2016y-05m-06d-14h-29m-58s).

On v4.6-rc6, the test failed thus:

 8< 
Subtest fbc-1p-primscrn-spr-indfb-fullscreen failed.
 DEBUG 
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: fbc.can_test
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: 
igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, 
tiling=0x101, size=14745600)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: 
igt_create_fb_with_bo_size(handle=6, pitch=10240)
(kms_frontbuffer_tracking:1914) DEBUG: Blue CRC:   pipe:[2ca73d01  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: 
igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, 
tiling=0x101, size=14745600)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: 
igt_create_fb_with_bo_size(handle=6, pitch=10240)
(kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: 
intel_gen(intel_get_drm_devid(fd)) >= 5
(kms_frontbuffer_tracking:1914) DEBUG: Rect 0 CRC: pipe:[febb8b20  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: 
intel_gen(intel_get_drm_devid(fd)) >= 5
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: 
!fbc_not_enough_stolen()
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: 
intel_gen(intel_get_drm_devid(fd)) >= 5
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: 
!fbc_not_enough_stolen()
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: 
igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, 
tiling=0x101, size=14745600)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: 
is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: 
igt_create_fb_with_bo_size(handle=6, pitch=10240)
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[febb8b20  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: 
!fbc_not_enough_stolen()
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[febb8b20  
  ] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) igt-core-INFO: Timed out: CRC reading
  END  
IGT-Version: 1.14-gc03a8ae6bf2f (x86_64) (Linux: 4.6.0-rc6 x86_64)
Primary screen: DP 2560x1440, crtc 26
FBC last action not supported
Can't test PSR: no usable eDP screen.
Sink CRC not supported: primary screen is not eDP
Timed out: CRC reading
Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.806s)
 >8 

On v4.6-rc6 plus drm-intel-nightly, the test apparently passed:

 8< 
IGT-Version: 1.14-gc03a8ae6bf2f (x86_64) (Linux: 4.6.0-rc6+intel-drm-nightly 
x86_64)
Primary screen: DP 2560x1440, crtc 26
FBC last action not supported
Can't test PSR: no usable eDP screen.

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

[Stefan Richter]

On May 08 Stefan Richter wrote:
> On May 05 Zanoni, Paulo R wrote:
> > If you don't want to keep carrying a manual revert, you can just boot
> > with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> > it would be good to know in case you still somehow see the machine
> > hangs even with FBC disabled.  
> 
> As expected, i915.enable_fbc=0 works fine.
> No freeze within 2.5 days uptime; tested on v4.6-rc6.

Furthermore, I checked out drm-intel.git (v4.6-rc6-962-g91567024d358
"drm-intel-nightly: 2016y-05m-06d-14h-29m-58s UTC integration manifest")
and applied "git diff v4.6-rc6..." on top of v4.6-rc6.

I booted the result once with default i915.enable_fbc, i.e. FBC enabled,
performed the test which Daniel asked for (I will post the results in
another message), then started X11.
  - The good news:  I was able to switch back and forth between the sddm
greeter screen on tty7, the text consoles at tty1...6, and the logger
at tty12 --- without getting any FIFO underrun messages and without
getting stuck with a blank screen.
  - The bad news:  Less than a minute after login into sddm, just after
having started openbox + lxpanel + konsole, the kernel froze again
without netconsole output.

I am now on 4.6.0-rc6+intel-drm-nightly with i915.enable_fbc=0.  This is
running fine so far.  (uptime is just 30 minutes now though, so that
doesn't say a lot.)  Again, switching between ttys works without FIFO
underruns, unlike plain v4.6-rc6.  Not sure if it is coincidence or if
this is because somebody fixed something.

Like v4.6-rc6 and older,4.6.0-rc6+intel-drm-nightly still exhibits the
following behaviour:  If I switch the displayport connected monitor off
and on again, the following messages are logged when the monitor comes on:
[drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun 
on pipe A
[drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun
Other than these messages, there is nothing extraordinary going on.
-- 
Stefan Richter
-==- -=-= -=---
http://arcgraph.de/sr/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

[Stefan Richter]

On May 05 Zanoni, Paulo R wrote:
> If you don't want to keep carrying a manual revert, you can just boot
> with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> it would be good to know in case you still somehow see the machine
> hangs even with FBC disabled.

As expected, i915.enable_fbc=0 works fine.
No freeze within 2.5 days uptime; tested on v4.6-rc6.
-- 
Stefan Richter
-==- -=-= -=---
http://arcgraph.de/sr/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

[Ville Syrjälä]

On Fri, May 06, 2016 at 09:22:49PM +0100, Chris Wilson wrote:
> On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrj...@linux.intel.com wrote:
> > @@ -730,9 +730,14 @@ int i915_suspend_switcheroo(struct drm_device *dev, 
> > pm_message_t state)
> >  static int i915_drm_resume(struct drm_device *dev)
> >  {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > +   int ret;
> >  
> > disable_rpm_wakeref_asserts(dev_priv);
> >  
> > +   ret = i915_ggtt_enable_hw(dev);
> > +   if (ret)
> > +   DRM_ERROR("failed to re-enable GGTT\n");
> 
> Would it not be fatal for resume as well? Failure means we can't use the
> GGTT, so all subsequent writes will be going into a random address.

Yeah, I assume things would blow up. The question is however, what can
we do in this case? We'd basically have to shut the entire driver down.
I don't think we have a way to do that?

-- 
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 v3 00/16] Pre-calculate SKL-style atomic watermarks

[Daniel Stone]

Hi Matt,

On 22 April 2016 at 00:16, Matt Roper  wrote:
> For a detailed explanation of this series, please see the original cover 
> letter:
>   https://lists.freedesktop.org/archives/intel-gfx/2016-April/091293.html
>
> This spin just incorporates the final review feedback from Maarten and
> hopefully kicks the CI system (I never got any CI test results back from v2).

For the series, with Maarten and Lyude's amendments:
Tested-by: Daniel Stone 

I was seeing pretty savage underflows on eDP+DP SKL, but these have
gone away with this patchset on top of -nightly.

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