[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable upfront link training on DDI platforms

2016-08-08 Thread Patchwork
== Series Details ==

Series: Enable upfront link training on DDI platforms
URL   : https://patchwork.freedesktop.org/series/10821/
State : failure

== Summary ==

Applying: drm/i915: Don't pass crtc_state to intel_dp_set_link_params()
Applying: drm/i915: Remove ddi_pll_sel from intel_crtc_state
Applying: drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions
Applying: drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_ddi.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: drm/i915/dp: Enable Upfront link training for typeC DP support on BXT
Applying: drm/i915: Split skl_get_dpll()
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_dpll_mgr.c
M   drivers/gpu/drm/i915/intel_dpll_mgr.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_dpll_mgr.h
Auto-merging drivers/gpu/drm/i915/intel_dpll_mgr.c
Applying: drm/i915/dp: Enable upfront link training on SKL
Applying: drm/i915: Split hsw_get_dpll()
fatal: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_dpll_mgr.c).
error: could not build fake ancestor
Patch failed at 0008 drm/i915: Split hsw_get_dpll()
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/skl: Add support for the SAGV, fix underrun hangs (rev6)

2016-08-08 Thread Patchwork
== Series Details ==

Series: drm/i915/skl: Add support for the SAGV, fix underrun hangs (rev6)
URL   : https://patchwork.freedesktop.org/series/9736/
State : success

== Summary ==

Series 9736v6 drm/i915/skl: Add support for the SAGV, fix underrun hangs
http://patchwork.freedesktop.org/api/1.0/series/9736/revisions/6/mbox

Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
fail   -> PASS   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-byt-n2820)

fi-hsw-i7-4770k  total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
fi-kbl-qkkr  total:107  pass:82   dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-i5-6260u  total:107  pass:98   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i7-6700k  total:107  pass:84   dwarn:0   dfail:0   fail:0   skip:22 
fi-snb-i7-2600   total:107  pass:77   dwarn:0   dfail:0   fail:0   skip:29 
ro-bdw-i5-5250u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5557U  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5600u  total:107  pass:79   dwarn:0   dfail:0   fail:0   skip:27 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:198  dwarn:0   dfail:0   fail:2   skip:40 
ro-hsw-i3-4010u  total:107  pass:87   dwarn:0   dfail:0   fail:0   skip:19 
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60 
ro-ivb-i7-3770   total:107  pass:80   dwarn:0   dfail:0   fail:0   skip:26 
ro-skl3-i5-6260u total:107  pass:98   dwarn:0   dfail:0   fail:0   skip:8  

Results at /archive/results/CI_IGT_test/RO_Patchwork_1769/

5df4316 drm-intel-nightly: 2016y-08m-08d-18h-35m-22s UTC integration manifest
4625cc9 drm/i915/skl: Add support for the SAGV, fix underrun hangs

___
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: Maarten's pre-g4x GPU reset regression fix + other reset stuff

2016-08-08 Thread Ville Syrjälä
On Sat, Aug 06, 2016 at 08:45:37AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Maarten's pre-g4x GPU reset regression fix + other reset 
> stuff
> URL   : https://patchwork.freedesktop.org/series/10731/
> State : failure
> 
> == Summary ==
> 
> Series 10731v1 drm/i915: Maarten's pre-g4x GPU reset regression fix + other 
> reset stuff
> http://patchwork.freedesktop.org/api/1.0/series/10731/revisions/1/mbox
> 
> Test kms_cursor_legacy:
> Subgroup basic-cursor-vs-flip-varying-size:
> pass   -> FAIL   (ro-ilk1-i5-650)

(kms_cursor_legacy:8107) DEBUG: Test requirement passed: target > 1
(kms_cursor_legacy:8107) DEBUG: Using a target of 32 cursor updates per 
half-vblank
(kms_cursor_legacy:8107) WARNING: page flip 11 was delayed, missed 2 frames
(kms_cursor_legacy:8107) CRITICAL: Test assertion failure function 
basic_cursor_vs_flip, file kms_cursor_legacy.c:670:
(kms_cursor_legacy:8107) CRITICAL: Failed assertion: vbl.sequence == 
vblank_start + 60
(kms_cursor_legacy:8107) CRITICAL: error: 11538 != 11536

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

> Subgroup basic-flip-vs-cursor-varying-size:
> pass   -> FAIL   (ro-snb-i7-2620M)
> fail   -> PASS   (ro-bdw-i5-5250u)

(kms_cursor_legacy:7751) DEBUG: Test requirement passed: target > 1
(kms_cursor_legacy:7751) DEBUG: Using a target of 64 cursor updates per 
half-vblank
(kms_cursor_legacy:7751) CRITICAL: Test assertion failure function 
basic_flip_vs_cursor, file kms_cursor_legacy.c:514:
(kms_cursor_legacy:7751) CRITICAL: Failed assertion: 
get_vblank(display->drm_fd, pipe, 0) == vblank_start
(kms_cursor_legacy:7751) CRITICAL: error: 13763 != 13762

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

> 
> fi-kbl-qkkr  total:244  pass:185  dwarn:29  dfail:0   fail:3   skip:27 
> ro-bdw-i5-5250u  total:240  pass:219  dwarn:4   dfail:0   fail:1   skip:16 
> ro-bdw-i7-5557U  total:240  pass:224  dwarn:0   dfail:0   fail:0   skip:16 
> ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
> ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
> ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
> ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
> ro-ilk-i7-620lm  total:240  pass:173  dwarn:1   dfail:0   fail:1   skip:65 
> ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
> ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
> ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
> ro-skl3-i5-6260u total:240  pass:223  dwarn:0   dfail:0   fail:3   skip:14 
> ro-snb-i7-2620M  total:240  pass:197  dwarn:0   dfail:0   fail:2   skip:41 
> ro-byt-n2820 failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1741/
> 
> b834992 drm-intel-nightly: 2016y-08m-05d-20h-40m-44s UTC integration manifest
> ed2ac6e drm/i915: Use the g4x+ approach on gen2 for handling display stuff 
> around GPU reset
> d29861b drm/i915: Introduce gpu_reset_clobbers_display()
> 893b403 drm/i915: Add a way to test the modeset done during gpu reset, v3.
> 617092d drm/i915: Fix modeset handling during gpu reset, v5.

-- 
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] ✗ Ro.CI.BAT: failure for drm/i915: Account for TSEG size when determining 865G stolen base

2016-08-08 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 11:25:22AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Account for TSEG size when determining 865G stolen base
> URL   : https://patchwork.freedesktop.org/series/10779/
> State : failure
> 
> == Summary ==
> 
> Series 10779v1 drm/i915: Account for TSEG size when determining 865G stolen 
> base
> http://patchwork.freedesktop.org/api/1.0/series/10779/revisions/1/mbox
> 
> Test drv_module_reload_basic:
> pass   -> SKIP   (fi-skl-i5-6260u)

rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use
rmmod: ERROR: Module i915 is in use

same old stuff

> Test kms_cursor_legacy:
> Subgroup basic-cursor-vs-flip-legacy:
> pass   -> FAIL   (ro-ilk1-i5-650)

(kms_cursor_legacy:8066) DEBUG: Test requirement passed: target > 1
(kms_cursor_legacy:8066) DEBUG: Using a target of 64 cursor updates per 
half-vblank
(kms_cursor_legacy:8066) WARNING: page flip 2 was delayed, missed 1 frames
(kms_cursor_legacy:8066) CRITICAL: Test assertion failure function 
basic_cursor_vs_flip, file kms_cursor_legacy.c:670:
(kms_cursor_legacy:8066) CRITICAL: Failed assertion: vbl.sequence == 
vblank_start + 60
(kms_cursor_legacy:8066) CRITICAL: error: 11071 != 11070

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

> 
> fi-hsw-i7-4770k  total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
> fi-kbl-qkkr  total:107  pass:83   dwarn:1   dfail:0   fail:0   skip:22 
> fi-skl-i5-6260u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
> fi-skl-i7-6700k  total:107  pass:84   dwarn:0   dfail:0   fail:0   skip:22 
> fi-snb-i7-2600   total:107  pass:77   dwarn:0   dfail:0   fail:0   skip:29 
> ro-bdw-i5-5250u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
> ro-bdw-i7-5557U  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
> ro-bdw-i7-5600u  total:94   pass:69   dwarn:0   dfail:0   fail:0   skip:24 
> ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
> ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
> ro-hsw-i3-4010u  total:107  pass:87   dwarn:0   dfail:0   fail:0   skip:19 
> ro-ilk1-i5-650   total:235  pass:172  dwarn:0   dfail:0   fail:3   skip:60 
> ro-ivb-i7-3770   total:107  pass:80   dwarn:0   dfail:0   fail:0   skip:26 
> ro-skl3-i5-6260u total:107  pass:98   dwarn:0   dfail:0   fail:0   skip:8  
> ro-bdw-i7-5600u failed to connect after reboot
> ro-hsw-i7-4770r failed to connect after reboot
> ro-ivb2-i7-3770 failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1761/
> 
> 8ca71ca drm-intel-nightly: 2016y-08m-08d-09h-02m-24s UTC integration manifest
> 32bc6d7 drm/i915: Account for TSEG size when determining 865G stolen base

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable upfront link training on DDI platforms

2016-08-08 Thread Patchwork
== Series Details ==

Series: Enable upfront link training on DDI platforms
URL   : https://patchwork.freedesktop.org/series/10821/
State : failure

== Summary ==

  CC [M]  drivers/gpu/drm/i915/intel_dsi.o
  CC [M]  drivers/gpu/drm/i915/intel_dsi_dcs_backlight.o
  LD  drivers/net/built-in.o
  CC [M]  drivers/gpu/drm/i915/intel_dsi_panel_vbt.o
  CC [M]  drivers/gpu/drm/i915/intel_dsi_pll.o
  LD  drivers/usb/built-in.o
  CC [M]  drivers/gpu/drm/i915/intel_dvo.o
  CC [M]  drivers/gpu/drm/i915/intel_hdmi.o
  CC [M]  drivers/gpu/drm/i915/intel_i2c.o
drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_bxt_upfront_link_train':
drivers/gpu/drm/i915/intel_ddi.c:2407:2: error: implicit declaration of 
function 'bxt_ddi_dp_set_dpll_hw_state' [-Werror=implicit-function-declaration]
  if (!bxt_ddi_dp_set_dpll_hw_state(clock, >config.hw_state)) {
  ^
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
  CC [M]  drivers/gpu/drm/i915/intel_sdvo.o
  CC [M]  drivers/gpu/drm/i915/intel_tv.o
  CC [M]  drivers/gpu/drm/i915/i915_vgpu.o
cc1: some warnings being treated as errors
scripts/Makefile.build:289: recipe for target 
'drivers/gpu/drm/i915/intel_ddi.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_ddi.o] Error 1
make[4]: *** Waiting for unfinished jobs
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:975: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/CI_Patchwork_build_2259

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


Re: [Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

2016-08-08 Thread Dave Airlie
On 8 August 2016 at 19:40, Daniel Vetter  wrote:
> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>> Hello there,
>>
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
>> requires 37 bits to represent, but ‘int’ only has 32 bits
>> [-Wshift-overflow=]
>>
>> Source code is
>>
>> #define   INTEL_BSM_MASK (0x << 20)
>>
>> Maybe something like
>>
>> #define   INTEL_BSM_MASK (0xUL<< 20)
>>
>> might be better.
>
> Yup. Care to bake this into a patch (with s-o-b and everything per
> Documentation/SubmittingPatches) so I can apply it?

Why would you want to apply a clearly incorrect patch :-)

INTEL_BSM_MASK is used in one place, on a 32-bit number

I'm not sure what it needs to be, but a 64-bit number it doesn't.

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


[Intel-gfx] [PATCH 0/9] Enable upfront link training on DDI platforms

2016-08-08 Thread Manasi Navare
This patch series enables upfront link training on DDI platforms
(SKL/BDW/HSW/BXT). They are based on some of the pacthes submitted
earlier by Ander and Durgadoss.

The upfront link training had to be factored out of long pulse
hanlder because of deadlock issues seen on DP MST cases.
Now the upfront link training takes place in intel_dp_mode_valid()
to find the maximum lane count and link rate at which the DP link
can be successfully trained. These values are used to prune the
invalid modes before modeset. Modeset makes use the upfront lane
count and link train values.

These patches have been validated for DP SST on DDI platforms
(SKL/HSW/BDW/BXT). They have also been tested for any regressions
on non DDI platforms (CHV).

Ander Conselvan de Oliveira (3):
  drm/i915: Don't pass crtc_state to intel_dp_set_link_params()
  drm/i915: Remove ddi_pll_sel from intel_crtc_state
  drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

Durgadoss R (2):
  drm/i915: Split bxt_ddi_pll_select()
  drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

Jim Bride (2):
  drm/i915: Split skl_get_dpll()
  drm/i915/dp: Enable upfront link training on SKL

Manasi Navare (2):
  drm/i915: Split hsw_get_dpll()
  drm/i915: Enable upfront link training support for HSW/BDW

 drivers/gpu/drm/i915/intel_ddi.c  | 207 +---
 drivers/gpu/drm/i915/intel_display.c  |  43 +--
 drivers/gpu/drm/i915/intel_dp.c   | 386 --
 drivers/gpu/drm/i915/intel_dp_link_training.c |   7 +-
 drivers/gpu/drm/i915/intel_dp_mst.c   |   9 +-
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 457 --
 drivers/gpu/drm/i915/intel_dpll_mgr.h |  15 +
 drivers/gpu/drm/i915/intel_drv.h  |  29 +-
 8 files changed, 776 insertions(+), 377 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v2 4/9] drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

2016-08-08 Thread Manasi Navare
From: Ander Conselvan de Oliveira 

Split intel_ddi_pre_enable() into encoder type specific versions that
don't depend on crtc_state. The necessary parameters are passed as
function arguments. This split will be necessary for implementing DP
upfront link training.

v2:
* Rebased onto kernel v4.7 (Jim)

Reviewed-by: Durgadoss R 
Signed-off-by: Ander Conselvan de Oliveira 

Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_ddi.c | 96 +++-
 1 file changed, 55 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8c87d21..dfb3fb6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1634,59 +1634,73 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
}
 }
 
-static void intel_ddi_pre_enable(struct intel_encoder *intel_encoder)
+static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
+   int link_rate, uint32_t lane_count,
+   struct intel_shared_dpll *pll,
+   bool link_mst)
 {
-   struct drm_encoder *encoder = _encoder->base;
-   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
-   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
-   enum port port = intel_ddi_get_encoder_port(intel_encoder);
-   int type = intel_encoder->type;
-
-   if (type == INTEL_OUTPUT_HDMI) {
-   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum port port = intel_ddi_get_encoder_port(encoder);
 
-   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
-   }
+   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
+link_mst);
 
-   if (type == INTEL_OUTPUT_EDP) {
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   if (encoder->type == INTEL_OUTPUT_EDP)
intel_edp_panel_on(intel_dp);
-   }
-
-   intel_ddi_clk_select(intel_encoder, crtc->config->shared_dpll);
 
-   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   intel_ddi_clk_select(encoder, pll);
+   intel_prepare_dp_ddi_buffers(encoder);
+   intel_ddi_init_dp_buf_reg(encoder);
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   intel_dp_start_link_train(intel_dp);
+   if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
+   intel_dp_stop_link_train(intel_dp);
+}
 
-   intel_prepare_dp_ddi_buffers(intel_encoder);
+static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
+ bool has_hdmi_sink,
+ struct drm_display_mode *adjusted_mode,
+ struct intel_shared_dpll *pll)
+{
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(>base);
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct drm_encoder *drm_encoder = >base;
+   enum port port = intel_ddi_get_encoder_port(encoder);
+   int level = intel_ddi_hdmi_level(dev_priv, port);
 
-   intel_dp_set_link_params(intel_dp, crtc->config->port_clock,
-crtc->config->lane_count,
-intel_crtc_has_type(crtc->config,
-
INTEL_OUTPUT_DP_MST));
+   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
+   intel_ddi_clk_select(encoder, pll);
+   intel_prepare_hdmi_ddi_buffers(encoder);
 
-   intel_ddi_init_dp_buf_reg(intel_encoder);
+   if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+   skl_ddi_set_iboost(encoder, level);
+   else if (IS_BROXTON(dev_priv))
+   bxt_ddi_vswing_sequence(dev_priv, level, port,
+   INTEL_OUTPUT_HDMI);
 
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
-   if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
-   intel_dp_stop_link_train(intel_dp);
-   } else if (type == INTEL_OUTPUT_HDMI) {
-   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
-   int level = intel_ddi_hdmi_level(dev_priv, port);
+   intel_hdmi->set_infoframes(drm_encoder, has_hdmi_sink, adjusted_mode);
+}
 
-   intel_prepare_hdmi_ddi_buffers(intel_encoder);
+static void intel_ddi_pre_enable(struct intel_encoder *intel_encoder)
+{
+   struct drm_encoder *encoder 

[Intel-gfx] [PATCH 1/9] drm/i915: Don't pass crtc_state to intel_dp_set_link_params()

2016-08-08 Thread Manasi Navare
From: Ander Conselvan de Oliveira 

Decouple intel_dp_set_link_params() from struct intel_crtc_state. This
will be useful for implementing DP upfront link training.

Reviewed-by: Durgadoss R 
Signed-off-by: Ander Conselvan de Oliveira 

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c|  5 -
 drivers/gpu/drm/i915/intel_dp.c | 14 +-
 drivers/gpu/drm/i915/intel_dp_mst.c |  6 --
 drivers/gpu/drm/i915/intel_drv.h|  3 ++-
 4 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c2df4e4..530ee9f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1637,7 +1637,10 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
 
intel_prepare_dp_ddi_buffers(intel_encoder);
 
-   intel_dp_set_link_params(intel_dp, crtc->config);
+   intel_dp_set_link_params(intel_dp, crtc->config->port_clock,
+crtc->config->lane_count,
+intel_crtc_has_type(crtc->config,
+
INTEL_OUTPUT_DP_MST));
 
intel_ddi_init_dp_buf_reg(intel_encoder);
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8fe2afa..39d5be5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1647,11 +1647,12 @@ found:
 }
 
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
- const struct intel_crtc_state *pipe_config)
+ int link_rate, uint8_t lane_count,
+ bool link_mst)
 {
-   intel_dp->link_rate = pipe_config->port_clock;
-   intel_dp->lane_count = pipe_config->lane_count;
-   intel_dp->link_mst = intel_crtc_has_type(pipe_config, 
INTEL_OUTPUT_DP_MST);
+   intel_dp->link_rate = link_rate;
+   intel_dp->lane_count = lane_count;
+   intel_dp->link_mst = link_mst;
 }
 
 static void intel_dp_prepare(struct intel_encoder *encoder)
@@ -1663,7 +1664,10 @@ static void intel_dp_prepare(struct intel_encoder 
*encoder)
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
 
-   intel_dp_set_link_params(intel_dp, crtc->config);
+   intel_dp_set_link_params(intel_dp, crtc->config->port_clock,
+crtc->config->lane_count,
+intel_crtc_has_type(crtc->config,
+INTEL_OUTPUT_DP_MST));
 
/*
 * There are four kinds of DP registers:
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 629337d..e654fea 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -173,8 +173,10 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder)
intel_ddi_clk_select(_dig_port->base, intel_crtc->config);
 
intel_prepare_dp_ddi_buffers(_dig_port->base);
-
-   intel_dp_set_link_params(intel_dp, intel_crtc->config);
+   intel_dp_set_link_params(intel_dp,
+intel_crtc->config->port_clock,
+intel_crtc->config->lane_count,
+true);
 
intel_ddi_init_dp_buf_reg(_dig_port->base);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c29a429..86d243e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1342,7 +1342,8 @@ bool intel_dp_init(struct drm_device *dev, i915_reg_t 
output_reg, enum port port
 bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 struct intel_connector *intel_connector);
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
- const struct intel_crtc_state *pipe_config);
+ int link_rate, uint8_t lane_count,
+ bool link_mst);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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


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

2016-08-08 Thread Manasi Navare
From: Durgadoss R 

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 v7:
* Move the upfront link training to intel_dp_mode_valid()
  to avoid a race condition with DP MST sideband comms. (Ville)
Changes since v6:
* Fix some initialization bugs on link_rate (Jim Bride)
* Use link_rate (and not link_bw) for upfront (Ville)
* Make intel_dp_upfront*() as a vfunc (Ander)
* The train_set_valid variable in intel_dp was removed due to
  issues in fast link training. So, to indicate the link train
  status, move the channel_eq inside intel_dp.
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 
Signed-off-by: Jim Bride 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  |  47 
 drivers/gpu/drm/i915/intel_dp.c   | 370 +++---
 drivers/gpu/drm/i915/intel_dp_link_training.c |   7 +-
 drivers/gpu/drm/i915/intel_drv.h  |  16 ++
 4 files changed, 337 insertions(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index dfb3fb6..3921230 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2378,6 +2378,53 @@ 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,
+ bool link_mst)
+{
+   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, link_mst);
+
+   DRM_DEBUG_KMS("Upfront link train %s: link_clock:%d lanes:%d\n",
+   intel_dp->channel_eq_status ? "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);
+
+   

[Intel-gfx] [PATCH 7/9] drm/i915/dp: Enable upfront link training on SKL

2016-08-08 Thread Manasi Navare
From: Jim Bride 

Split the PLL selection code out of the BXT upfront link training
implementation and into a stand-alone function in order to allow
for the implementation of a platform neutral upfront link training
function, and then enable upfront link training for Skylake.

Signed-off-by: Jim Bride 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 58 ---
 drivers/gpu/drm/i915/intel_dp.c   |  4 +--
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 38 +++
 drivers/gpu/drm/i915/intel_dpll_mgr.h |  2 ++
 drivers/gpu/drm/i915/intel_drv.h  |  4 ++-
 5 files changed, 85 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3921230..ed9ebca 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2378,8 +2378,43 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port 
*intel_dig_port)
return connector;
 }
 
+struct intel_shared_dpll *
+intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int clock)
+{
+   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_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct intel_shared_dpll *pll = NULL;
+   struct intel_shared_dpll_config tmp_pll_config;
+   enum intel_dpll_id dpll_id;
 
-bool intel_bxt_upfront_link_train(struct intel_dp *intel_dp,
+   if (IS_BROXTON(dev_priv)) {
+   dpll_id =  (enum intel_dpll_id)dig_port->port;
+   /*
+* 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 in use. active_mask:%x\n",
+ pll->active_mask);
+   pll = NULL;
+   }
+   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;
+   }
+   } else if (IS_SKYLAKE(dev_priv)) {
+   pll = skl_find_link_pll(dev_priv, clock);
+   }
+   return pll;
+}
+
+bool intel_ddi_upfront_link_train(struct intel_dp *intel_dp,
  int clock, uint8_t lane_count,
  bool link_mst)
 {
@@ -2388,28 +2423,15 @@ bool intel_bxt_upfront_link_train(struct intel_dp 
*intel_dp,
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);
+   pll = intel_ddi_get_link_dpll(intel_dp, clock);
+   if (pll == NULL) {
+   DRM_ERROR("Could not find DPLL for link training.\n");
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, link_mst);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4c03e28..572119e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5762,8 +5762,8 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 
/* Initialize upfront link training vfunc for DP */
if (intel_encoder->type != INTEL_OUTPUT_EDP) {
-   if (IS_BROXTON(dev))
-   intel_dp->upfront_link_train = 
intel_bxt_upfront_link_train;
+   if (IS_BROXTON(dev) || IS_SKYLAKE(dev))
+   intel_dp->upfront_link_train = 
intel_ddi_upfront_link_train;
}
 
/* eDP only on port B and/or C on vlv/chv */
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 

[Intel-gfx] [PATCH 9/9] drm/i915: Enable upfront link training support for HSW/BDW

2016-08-08 Thread Manasi Navare
Get the PLLs for HSW/BDW using the platform specific function
and add hooks for enabling upfront link training on HSW and BDW.

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 ++
 drivers/gpu/drm/i915/intel_dp.c  | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ed9ebca..fd0c538 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2410,6 +2410,8 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int 
clock)
}
} else if (IS_SKYLAKE(dev_priv)) {
pll = skl_find_link_pll(dev_priv, clock);
+   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
+   pll = hsw_ddi_dp_get_dpll(encoder, clock);
}
return pll;
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 572119e..25190fa 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5762,8 +5762,10 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 
/* Initialize upfront link training vfunc for DP */
if (intel_encoder->type != INTEL_OUTPUT_EDP) {
-   if (IS_BROXTON(dev) || IS_SKYLAKE(dev))
+   if (IS_BROXTON(dev) || IS_SKYLAKE(dev) ||
+   IS_BROADWELL(dev) || IS_HASWELL(dev))
intel_dp->upfront_link_train = 
intel_ddi_upfront_link_train;
+
}
 
/* eDP only on port B and/or C on vlv/chv */
-- 
1.9.1

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


[Intel-gfx] [PATCH 6/9] drm/i915: Split skl_get_dpll()

2016-08-08 Thread Manasi Navare
From: Jim Bride 

Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code does not directly depend on
crtc state, so that the code can be used for upfront link training.

Signed-off-by: Jim Bride 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 131 +-
 drivers/gpu/drm/i915/intel_dpll_mgr.h |   4 ++
 2 files changed, 87 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 61d2311..8ce220e 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1172,75 +1172,110 @@ skip_remaining_dividers:
return true;
 }
 
-static struct intel_shared_dpll *
-skl_get_dpll(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
-struct intel_encoder *encoder)
+static bool skl_ddi_hdmi_pll_dividers(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state,
+ int clock)
 {
-   struct intel_shared_dpll *pll;
uint32_t ctrl1, cfgcr1, cfgcr2;
-   int clock = crtc_state->port_clock;
+   struct skl_wrpll_params wrpll_params = { 0, };
 
/*
 * See comment in intel_dpll_hw_state to understand why we always use 0
 * as the DPLL id in this function.
 */
-
ctrl1 = DPLL_CTRL1_OVERRIDE(0);
 
-   if (encoder->type == INTEL_OUTPUT_HDMI) {
-   struct skl_wrpll_params wrpll_params = { 0, };
+   ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
 
-   ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
+   if (!skl_ddi_calculate_wrpll(clock * 1000, _params))
+   return false;
 
-   if (!skl_ddi_calculate_wrpll(clock * 1000, _params))
-   return NULL;
+   cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
+   DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
+   wrpll_params.dco_integer;
+
+   cfgcr2 = DPLL_CFGCR2_QDIV_RATIO(wrpll_params.qdiv_ratio) |
+   DPLL_CFGCR2_QDIV_MODE(wrpll_params.qdiv_mode) |
+   DPLL_CFGCR2_KDIV(wrpll_params.kdiv) |
+   DPLL_CFGCR2_PDIV(wrpll_params.pdiv) |
+   wrpll_params.central_freq;
+
+   memset(_state->dpll_hw_state, 0,
+  sizeof(crtc_state->dpll_hw_state));
+
+   crtc_state->dpll_hw_state.ctrl1 = ctrl1;
+   crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
+   crtc_state->dpll_hw_state.cfgcr2 = cfgcr2;
+   return true;
+}
+
+
+bool skl_ddi_dp_set_dpll_hw_state(int clock,
+ struct intel_dpll_hw_state *dpll_hw_state)
+{
+   uint32_t ctrl1;
+
+   /*
+* See comment in intel_dpll_hw_state to understand why we always use 0
+* as the DPLL id in this function.
+*/
+   ctrl1 = DPLL_CTRL1_OVERRIDE(0);
+   switch (clock / 2) {
+   case 81000:
+   ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, 0);
+   break;
+   case 135000:
+   ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1350, 0);
+   break;
+   case 27:
+   ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2700, 0);
+   break;
+   /* eDP 1.4 rates */
+   case 162000:
+   ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1620, 0);
+   break;
+   case 108000:
+   ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1080, 0);
+   break;
+   case 216000:
+   ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2160, 0);
+   break;
+   }
 
-   cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
-DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
-wrpll_params.dco_integer;
+   dpll_hw_state->ctrl1 = ctrl1;
+   return true;
+}
 
-   cfgcr2 = DPLL_CFGCR2_QDIV_RATIO(wrpll_params.qdiv_ratio) |
-DPLL_CFGCR2_QDIV_MODE(wrpll_params.qdiv_mode) |
-DPLL_CFGCR2_KDIV(wrpll_params.kdiv) |
-DPLL_CFGCR2_PDIV(wrpll_params.pdiv) |
-wrpll_params.central_freq;
+static struct intel_shared_dpll *
+skl_get_dpll(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
+struct intel_encoder *encoder)
+{
+   struct intel_shared_dpll *pll;
+   int clock = crtc_state->port_clock;
+   bool bret;
+   struct intel_dpll_hw_state dpll_hw_state;
+
+   memset(_hw_state, 0, sizeof(dpll_hw_state));
+
+   if (encoder->type == INTEL_OUTPUT_HDMI) {
+   bret = skl_ddi_hdmi_pll_dividers(crtc, crtc_state, clock);
+   if (!bret) {
+   DRM_DEBUG_KMS("Could not get HDMI pll dividers.\n");
+   return 

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

2016-08-08 Thread Manasi Navare
From: 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)

Reviewed-by: Durgadoss R 
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 530ee9f..8c87d21 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -546,6 +546,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.
@@ -561,7 +582,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
struct drm_i915_private *dev_priv = to_i915(dev);
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);
@@ -592,8 +613,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. */
@@ -870,7 +892,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);
 
@@ -918,7 +940,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;
@@ -1586,13 +1608,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  */
@@ -1600,14 +1624,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);
-   

[Intel-gfx] [PATCH 8/9] drm/i915: Split hsw_get_dpll()

2016-08-08 Thread Manasi Navare
Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code that calculates the pll
so that it doesn't depend on crtc state.
This will be used for acquiring port pll when doing
upfront link training.

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 90 ++-
 drivers/gpu/drm/i915/intel_dpll_mgr.h |  6 +++
 2 files changed, 63 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index ddb28fd..29d818f 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -705,11 +705,65 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
*r2_out = best.r2;
 }
 
+static struct intel_shared_dpll *hsw_ddi_hdmi_get_dpll(int clock,
+  struct intel_crtc *crtc,
+  struct intel_crtc_state 
*crtc_state)
+{
+   struct intel_shared_dpll *pll;
+   uint32_t val;
+   unsigned p, n2, r2;
+
+   hsw_ddi_calculate_wrpll(clock * 1000, , , );
+
+   val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
+ WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
+ WRPLL_DIVIDER_POST(p);
+
+   crtc_state->dpll_hw_state.wrpll = val;
+
+   pll = intel_find_shared_dpll(crtc, crtc_state,
+DPLL_ID_WRPLL1, DPLL_ID_WRPLL2);
+
+   if (!pll)
+   return NULL;
+
+   return pll;
+}
+
+struct intel_shared_dpll *hsw_ddi_dp_get_dpll(struct intel_encoder *encoder,
+ int clock)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_shared_dpll *pll;
+   enum intel_dpll_id pll_id;
+
+   switch (clock / 2) {
+   case 81000:
+   pll_id = DPLL_ID_LCPLL_810;
+   break;
+   case 135000:
+   pll_id = DPLL_ID_LCPLL_1350;
+   break;
+   case 27:
+   pll_id = DPLL_ID_LCPLL_2700;
+   break;
+   default:
+   DRM_DEBUG_KMS("Invalid clock for DP: %d\n", clock);
+   return NULL;
+   }
+
+   pll = intel_get_shared_dpll_by_id(dev_priv, pll_id);
+
+   if (!pll)
+   return NULL;
+
+   return pll;
+}
+
 static struct intel_shared_dpll *
 hsw_get_dpll(struct intel_crtc *crtc, struct intel_crtc_state *crtc_state,
 struct intel_encoder *encoder)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_shared_dpll *pll;
int clock = crtc_state->port_clock;
 
@@ -717,41 +771,12 @@ hsw_get_dpll(struct intel_crtc *crtc, struct 
intel_crtc_state *crtc_state,
   sizeof(crtc_state->dpll_hw_state));
 
if (encoder->type == INTEL_OUTPUT_HDMI) {
-   uint32_t val;
-   unsigned p, n2, r2;
-
-   hsw_ddi_calculate_wrpll(clock * 1000, , , );
-
-   val = WRPLL_PLL_ENABLE | WRPLL_PLL_LCPLL |
- WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
- WRPLL_DIVIDER_POST(p);
-
-   crtc_state->dpll_hw_state.wrpll = val;
-
-   pll = intel_find_shared_dpll(crtc, crtc_state,
-DPLL_ID_WRPLL1, DPLL_ID_WRPLL2);
+   pll = hsw_ddi_hdmi_get_dpll(clock, crtc, crtc_state);
 
} else if (encoder->type == INTEL_OUTPUT_DP ||
   encoder->type == INTEL_OUTPUT_DP_MST ||
   encoder->type == INTEL_OUTPUT_EDP) {
-   enum intel_dpll_id pll_id;
-
-   switch (clock / 2) {
-   case 81000:
-   pll_id = DPLL_ID_LCPLL_810;
-   break;
-   case 135000:
-   pll_id = DPLL_ID_LCPLL_1350;
-   break;
-   case 27:
-   pll_id = DPLL_ID_LCPLL_2700;
-   break;
-   default:
-   DRM_DEBUG_KMS("Invalid clock for DP: %d\n", clock);
-   return NULL;
-   }
-
-   pll = intel_get_shared_dpll_by_id(dev_priv, pll_id);
+   pll = hsw_ddi_dp_get_dpll(encoder, clock);
 
} else if (encoder->type == INTEL_OUTPUT_ANALOG) {
if (WARN_ON(crtc_state->port_clock / 2 != 135000))
@@ -774,7 +799,6 @@ hsw_get_dpll(struct intel_crtc *crtc, struct 
intel_crtc_state *crtc_state,
return pll;
 }
 
-
 static const struct intel_shared_dpll_funcs hsw_ddi_wrpll_funcs = {
.enable = hsw_ddi_wrpll_enable,
.disable = hsw_ddi_wrpll_disable,
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h 
b/drivers/gpu/drm/i915/intel_dpll_mgr.h
index ec0fe66..f438535 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
+++ 

[Intel-gfx] [PATCH v2 3/9] drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

2016-08-08 Thread Manasi Navare
From: Ander Conselvan de Oliveira 

Split intel_ddi_pre_enable() into encoder type specific versions that
don't depend on crtc_state. The necessary parameters are passed as
function arguments. This split will be necessary for implementing DP
upfront link training.

v2:
* Rebased onto kernel v4.7 (Jim)

Reviewed-by: Durgadoss R 
Signed-off-by: Ander Conselvan de Oliveira 

Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_ddi.c | 96 +++-
 1 file changed, 55 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8c87d21..dfb3fb6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1634,59 +1634,73 @@ void intel_ddi_clk_select(struct intel_encoder *encoder,
}
 }
 
-static void intel_ddi_pre_enable(struct intel_encoder *intel_encoder)
+static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
+   int link_rate, uint32_t lane_count,
+   struct intel_shared_dpll *pll,
+   bool link_mst)
 {
-   struct drm_encoder *encoder = _encoder->base;
-   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
-   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
-   enum port port = intel_ddi_get_encoder_port(intel_encoder);
-   int type = intel_encoder->type;
-
-   if (type == INTEL_OUTPUT_HDMI) {
-   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum port port = intel_ddi_get_encoder_port(encoder);
 
-   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
-   }
+   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
+link_mst);
 
-   if (type == INTEL_OUTPUT_EDP) {
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   if (encoder->type == INTEL_OUTPUT_EDP)
intel_edp_panel_on(intel_dp);
-   }
-
-   intel_ddi_clk_select(intel_encoder, crtc->config->shared_dpll);
 
-   if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   intel_ddi_clk_select(encoder, pll);
+   intel_prepare_dp_ddi_buffers(encoder);
+   intel_ddi_init_dp_buf_reg(encoder);
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   intel_dp_start_link_train(intel_dp);
+   if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
+   intel_dp_stop_link_train(intel_dp);
+}
 
-   intel_prepare_dp_ddi_buffers(intel_encoder);
+static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
+ bool has_hdmi_sink,
+ struct drm_display_mode *adjusted_mode,
+ struct intel_shared_dpll *pll)
+{
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(>base);
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct drm_encoder *drm_encoder = >base;
+   enum port port = intel_ddi_get_encoder_port(encoder);
+   int level = intel_ddi_hdmi_level(dev_priv, port);
 
-   intel_dp_set_link_params(intel_dp, crtc->config->port_clock,
-crtc->config->lane_count,
-intel_crtc_has_type(crtc->config,
-
INTEL_OUTPUT_DP_MST));
+   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
+   intel_ddi_clk_select(encoder, pll);
+   intel_prepare_hdmi_ddi_buffers(encoder);
 
-   intel_ddi_init_dp_buf_reg(intel_encoder);
+   if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
+   skl_ddi_set_iboost(encoder, level);
+   else if (IS_BROXTON(dev_priv))
+   bxt_ddi_vswing_sequence(dev_priv, level, port,
+   INTEL_OUTPUT_HDMI);
 
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
-   if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
-   intel_dp_stop_link_train(intel_dp);
-   } else if (type == INTEL_OUTPUT_HDMI) {
-   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
-   int level = intel_ddi_hdmi_level(dev_priv, port);
+   intel_hdmi->set_infoframes(drm_encoder, has_hdmi_sink, adjusted_mode);
+}
 
-   intel_prepare_hdmi_ddi_buffers(intel_encoder);
+static void intel_ddi_pre_enable(struct intel_encoder *intel_encoder)
+{
+   struct drm_encoder *encoder 

[Intel-gfx] [drm-intel:topic/drm-misc 5/18] drivers/gpu/drm/i915/intel_display.c:14148:23: error: 'struct drm_plane_state' has no member named 'clip'

2016-08-08 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   cfc5adea1955ee8ddb62cc0d20ee454472033b6a
commit: 936e71e314d393cd74c42c81b00b2092330c802d [5/18] drm/i915: Use 
drm_plane_state.{src,dst,visible}
config: i386-randconfig-s0-201632 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout 936e71e314d393cd74c42c81b00b2092330c802d
# save the attached .config to linux build tree
make ARCH=i386 

Note: the drm-intel/topic/drm-misc HEAD 
cfc5adea1955ee8ddb62cc0d20ee454472033b6a builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_display.c: In function 
'intel_check_primary_plane':
>> drivers/gpu/drm/i915/intel_display.c:14148:23: error: 'struct 
>> drm_plane_state' has no member named 'clip'
  >base.clip,
  ^
   drivers/gpu/drm/i915/intel_display.c: In function 'intel_check_cursor_plane':
   drivers/gpu/drm/i915/intel_display.c:14341:22: error: 'struct 
drm_plane_state' has no member named 'clip'
 >base.clip,
 ^
   drivers/gpu/drm/i915/intel_display.c: In function 
'intel_check_primary_plane':
>> drivers/gpu/drm/i915/intel_display.c:14153:1: warning: control reaches end 
>> of non-void function [-Wreturn-type]
}
^

vim +14148 drivers/gpu/drm/i915/intel_display.c

 14142  can_position = true;
 14143  }
 14144  
 14145  return drm_plane_helper_check_update(plane, crtc, fb,
 14146   >base.src,
 14147   >base.dst,
 14148   >base.clip,
 14149   state->base.rotation,
 14150   min_scale, max_scale,
 14151   can_position, true,
 14152   >base.visible);
 14153  }
 14154  
 14155  static void intel_begin_crtc_commit(struct drm_crtc *crtc,
 14156  struct drm_crtc_state 
*old_crtc_state)

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


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


[Intel-gfx] [drm-intel:topic/drm-misc 4/18] DocBook: drivers/gpu/drm/drm_plane_helper.c:248: warning: No description found for parameter 'dst'

2016-08-08 Thread kbuild test robot
tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   cfc5adea1955ee8ddb62cc0d20ee454472033b6a
commit: df86af9133b4958a04c44828d29617eb1a6ff31c [4/18] drm/plane-helper: Add 
drm_plane_helper_check_state()
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/drm_plane_helper.c:248: warning: No description found for 
>> parameter 'dst'
>> drivers/gpu/drm/drm_plane_helper.c:248: warning: Excess function parameter 
>> 'dest' description in 'drm_plane_helper_check_update'
   drivers/gpu/drm/drm_plane_helper.c:247: warning: No description found for 
parameter 'dst'
   drivers/gpu/drm/drm_plane_helper.c:247: warning: Excess function parameter 
'dest' description in 'drm_plane_helper_check_update'
   drivers/gpu/drm/i915/i915_vgpu.c:105: warning: No description found for 
parameter 'dev_priv'
   drivers/gpu/drm/i915/i915_vgpu.c:184: warning: No description found for 
parameter 'dev_priv'
   drivers/gpu/drm/i915/i915_vgpu.c:184: warning: Excess function parameter 
'dev' description in 'intel_vgt_balloon'
   drivers/gpu/drm/i915/i915_vgpu.c:106: warning: No description found for 
parameter 'dev_priv'
   drivers/gpu/drm/i915/i915_vgpu.c:185: warning: No description found for 
parameter 'dev_priv'
   drivers/gpu/drm/i915/i915_vgpu.c:185: warning: Excess function parameter 
'dev' description in 'intel_vgt_balloon'
   drivers/gpu/drm/i915/i915_gem.c:929: warning: No description found for 
parameter 'i915'
   drivers/gpu/drm/i915/i915_gem.c:929: warning: Excess function parameter 
'dev' description in 'i915_gem_gtt_pwrite_fast'
   drivers/gpu/drm/i915/intel_hotplug.c:543: warning: Excess function parameter 
'enabled' description in 'intel_hpd_poll_init'
   drivers/gpu/drm/i915/intel_hotplug.c:544: warning: Excess function parameter 
'enabled' description in 'intel_hpd_poll_init'
   drivers/gpu/drm/i915/intel_fbc.c:1087: warning: No description found for 
parameter 'crtc_state'
   drivers/gpu/drm/i915/intel_fbc.c:1087: warning: No description found for 
parameter 'plane_state'
   drivers/gpu/drm/i915/intel_fbc.c:1088: warning: No description found for 
parameter 'crtc_state'
   drivers/gpu/drm/i915/intel_fbc.c:1088: warning: No description found for 
parameter 'plane_state'
   drivers/gpu/drm/drm_crtc.c:1272: WARNING: Inline literal start-string 
without end-string.
   drivers/gpu/drm/drm_crtc.c:1387: WARNING: Inline literal start-string 
without end-string.
   include/drm/drm_crtc.h:1202: WARNING: Inline literal start-string without 
end-string.
   include/drm/drm_crtc.h:1255: WARNING: Inline literal start-string without 
end-string.
   include/drm/drm_crtc.h:1268: WARNING: Inline literal start-string without 
end-string.
   include/drm/drm_crtc.h:1272: WARNING: Inline literal start-string without 
end-string.
   drivers/gpu/drm/drm_irq.c:718: WARNING: Option list ends without a blank 
line; unexpected unindent.
   drivers/gpu/drm/drm_fb_helper.c:2196: WARNING: Inline emphasis start-string 
without end-string.
   drivers/gpu/drm/drm_simple_kms_helper.c:156: WARNING: Inline literal 
start-string without end-string.
   include/drm/drm_gem.h:212: WARNING: Inline emphasis start-string without 
end-string.
   drivers/gpu/drm/i915/intel_uncore.c:1622: ERROR: Unexpected indentation.
   drivers/gpu/drm/i915/intel_uncore.c:1623: WARNING: Block quote ends without 
a blank line; unexpected unindent.
   drivers/gpu/drm/i915/intel_uncore.c:1656: ERROR: Unexpected indentation.
   drivers/gpu/drm/i915/intel_uncore.c:1657: WARNING: Block quote ends without 
a blank line; unexpected unindent.
   drivers/gpu/drm/i915/i915_vgpu.c:178: WARNING: Literal block ends without a 
blank line; unexpected unindent.
   drivers/gpu/drm/i915/intel_audio.c:54: WARNING: Inline emphasis start-string 
without end-string.
   drivers/gpu/drm/i915/intel_audio.c:54: WARNING: Inline emphasis start-string 
without end-string.
   drivers/gpu/drm/i915/intel_lrc.c:1166: ERROR: Unexpected indentation.
   drivers/gpu/drm/i915/intel_lrc.c:1167: WARNING: Block quote ends without a 
blank line; unexpected unindent.
   drivers/gpu/drm/i915/intel_guc_fwif.h:159: WARNING: Block quote ends without 
a blank line; unexpected unindent.
   drivers/gpu/drm/i915/intel_guc_fwif.h:178: WARNING: Enumerated list ends 
without a blank line; unexpected unindent.
   Documentation/gpu/drm-kms.rst:13: WARNING: Could not lex literal_block as 
"C". Highlighting skipped.
   Documentation/gpu/drm-kms-helpers.rst:16: WARNING: Could not lex 
literal_block as "C". Highlighting skipped.
   Documentation/gpu/i915.rst:58: WARNING: Could not lex literal_block as "C". 
Highlighting skipped.

vim +/dst +248 drivers/gpu/drm/drm_plane_helper.c

   232   * RETURNS:
   233   * Zero if update appears valid, error code on failure
   234   */
   235  int drm_plane_helper_check_update(struct drm_plane *plane,
   236struct drm_crtc *crtc,
   237struct drm_framebuffer *fb,
   238

[Intel-gfx] [PATCH v10] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-08 Thread Lyude
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

Changes since v9:
 - Only enable/disable sagv on Skylake
Changes since v8:
 - Add intel_state->modeset guard to the conditional for
   skl_enable_sagv()
Changes since v7:
 - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
   all we use it for anyway)
 - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
 - Fix a styling error that snuck past me
Changes since v6:
 - Protect skl_enable_sagv() with intel_state->modeset conditional in
   intel_atomic_commit_tail()
Changes since v5:
 - Don't use is_power_of_2. Makes things confusing
 - Don't use the old state to figure out whether or not to
   enable/disable the sagv, use the new one
 - Split the loop in skl_disable_sagv into it's own function
 - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
 - Use time_before() to compare timeout to jiffies
Changes since v2:
 - Really apply minor style nitpicks to patch this time
Changes since v1:
 - Added comments about this probably being one of the requirements to
   fixing Skylake's watermark issues
 - Minor style nitpicks from Matt Roper
 - Disable these functions on Broxton, since it doesn't have an SAGV

Reviewed-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Lyude 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org

squash! drm/i915/skl: Add support for the SAGV, fix underrun hangs

squash! drm/i915/skl: Add support for the SAGV, fix underrun hangs

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_reg.h  |   4 ++
 drivers/gpu/drm/i915/intel_display.c |  12 
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 112 +++
 5 files changed, 132 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index feec00f..eb449f6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1948,6 +1948,8 @@ struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
 
+   bool skl_sagv_enabled;
+
struct {
/*
 * Raw watermark latency values:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f38a5e2..f7e0bc2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7170,6 +7170,10 @@ enum {
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ  0x17
 #define   DISPLAY_IPS_CONTROL  0x19
 #define  HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
+#define   GEN9_PCODE_SAGV_CONTROL  0x21
+#define GEN9_SAGV_DISABLE  0x0
+#define GEN9_SAGV_IS_DISABLED  0x1
+#define GEN9_SAGV_DYNAMIC_FREQ  0x3
 #define GEN6_PCODE_DATA  

[Intel-gfx] [PATCH v10] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-08 Thread Lyude
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

Changes since v9:
 - Only enable/disable sagv on Skylake
Changes since v8:
 - Add intel_state->modeset guard to the conditional for
   skl_enable_sagv()
Changes since v7:
 - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
   all we use it for anyway)
 - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
 - Fix a styling error that snuck past me
Changes since v6:
 - Protect skl_enable_sagv() with intel_state->modeset conditional in
   intel_atomic_commit_tail()
Changes since v5:
 - Don't use is_power_of_2. Makes things confusing
 - Don't use the old state to figure out whether or not to
   enable/disable the sagv, use the new one
 - Split the loop in skl_disable_sagv into it's own function
 - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
 - Use time_before() to compare timeout to jiffies
Changes since v2:
 - Really apply minor style nitpicks to patch this time
Changes since v1:
 - Added comments about this probably being one of the requirements to
   fixing Skylake's watermark issues
 - Minor style nitpicks from Matt Roper
 - Disable these functions on Broxton, since it doesn't have an SAGV

Reviewed-by: Matt Roper 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Lyude 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org

squash! drm/i915/skl: Add support for the SAGV, fix underrun hangs

squash! drm/i915/skl: Add support for the SAGV, fix underrun hangs

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_reg.h  |   4 ++
 drivers/gpu/drm/i915/intel_display.c |  12 
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 112 +++
 5 files changed, 132 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index feec00f..eb449f6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1948,6 +1948,8 @@ struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
 
+   bool skl_sagv_enabled;
+
struct {
/*
 * Raw watermark latency values:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f38a5e2..f7e0bc2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7170,6 +7170,10 @@ enum {
 #define   HSW_PCODE_DE_WRITE_FREQ_REQ  0x17
 #define   DISPLAY_IPS_CONTROL  0x19
 #define  HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL  0x1A
+#define   GEN9_PCODE_SAGV_CONTROL  0x21
+#define GEN9_SAGV_DISABLE  0x0
+#define GEN9_SAGV_IS_DISABLED  0x1
+#define GEN9_SAGV_DYNAMIC_FREQ  0x3
 #define GEN6_PCODE_DATA  

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

2016-08-08 Thread Zanoni, Paulo R
Em Seg, 2016-08-08 às 19:35 +0100, Chris Wilson escreveu:
> On Mon, Aug 08, 2016 at 06:25:49PM +, Zanoni, Paulo R wrote:
> > 
> > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> > > 
> > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > > > 
> > > > 
> > > > Reviewed-by: Lyude 
> > > 
> > > Merged to dinq.  Thanks for the quick review.
> > 
> > Regression? This patch makes my SKL machine fail any modesets. I
> > now
> > boot to a blinking screen where X keeps trying to start and fails.
> 
> -intel has been fixing up failed multi-CRTC modesets since seemingly
> forever on skl, that fail due to WM being exceeded. And why would
> modesetting even be trying to use a non-tiled framebuffer?

I'm just using my distro's default driver, and Debian uses modesetting
now.

I did switch to xf86-video-intel and I found something interesting: the
machine boots correctly, but then if I stop+restart lightdm, I get a
black screen. The difference here is that X doesn't abort, it tries to
keep working despite the black screen:

[46.483] (EE) intel(0): failed to set mode: Invalid argument [22]
[46.485] (II) intel(0): EDID vendor "SDC", prod id 16970
[46.485] (II) intel(0): Printing DDC gathered Modelines:
[46.485] (II) intel(0): Modeline "3200x1800"x0.0  361.31  3200 3248
3280 3316  1800 1802 1807 1816 -hsync -vsync (109.0 kHz eP)
[46.485] (II) intel(0): Modeline "3200x1800"x0.0  361.31  3200 3248
3280 3680  1800 1802 1807 2045 -hsync -vsync (98.2 kHz e)
[46.794] (--) intel(0): HDMI max TMDS frequency 225000KHz
[46.969] (EE) intel(0): failed to set mode: Invalid argument [22]

And dmesg has the same message as when using xf86-video-modesetting:

[   46.928018] [drm:skl_compute_plane_wm] Requested display
configuration exceeds system watermark limitations
[   46.928021] [drm:skl_compute_plane_wm] Plane 1.0: blocks required =
4/0, lines required = 1/31

Notice that this is the distro's driver version:
2:2.99.917+git20160706-1

So it looks like switching back to xf86-video-intel won't be a perfect
fix.

Anyway, while using the DDX to work around Kernel bugs may have some
benefits, it's probably best to try to push for an appropriate Kernel
fix, especially now that xf86-video-modesetting is gaining some market
share...

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


Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

2016-08-08 Thread Zanoni, Paulo R
Em Seg, 2016-08-08 às 18:25 +, Zanoni, Paulo R escreveu:
> Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> > 
> > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > > 
> > > 
> > > Reviewed-by: Lyude 
> > 
> > Merged to dinq.  Thanks for the quick review.
> 
> Regression? This patch makes my SKL machine fail any modesets. I now
> boot to a blinking screen where X keeps trying to start and fails.
> 
> Xorg.0.log gives me:
> [   273.512] (EE) modeset(0): failed to set mode: Invalid argument
> 
> 
> On the dmesg side, these are the more suspicious messages:
> 
> [  273.583659] [drm:skl_compute_plane_wm] Requested display
> configuration exceeds system watermark limitations
> [  273.583663] [drm:skl_compute_plane_wm] Plane 1.0: blocks required
> =
> 4/0, lines required = 1/31
> 
> 
> I tried applying Lyude's series to nightly to see if it fixes
> something, but it looks like patch 2 doesn't apply.

The patches do apply, I was confused by the email threading and mixed
patch 6 v9 with patch 2. Lyude's series fix the regression :).

> 
> > 
> > 
> > 
> > Matt
> > 
> > > 
> > > 
> > > 
> > > On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote:
> > > > 
> > > > 
> > > > The bspec was updated a couple weeks ago to add an extra block
> > > > per
> > > > line
> > > > to plane watermark calculations for linear pixel formats.
> > > > 
> > > > Bspec update 115327 description:
> > > >   "Gen9+ - Updated the plane blocks per line calculation for
> > > > linear
> > > >   cases. Adds +1 for all linear cases to handle the non-block
> > > > aligned
> > > >   stride cases."
> > > > 
> > > > Cc: Lyude 
> > > > Signed-off-by: Matt Roper 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_pm.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 4317cdf..6bd352a 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -3352,6 +3352,8 @@ static uint32_t skl_wm_method2(uint32_t
> > > > pixel_rate, uint32_t pipe_htotal,
> > > >     plane_bytes_per_line *= 4;
> > > >     plane_blocks_per_line =
> > > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > > >     plane_blocks_per_line /= 4;
> > > > +   } else if (tiling == DRM_FORMAT_MOD_NONE) {
> > > > +   plane_blocks_per_line =
> > > > DIV_ROUND_UP(plane_bytes_per_line, 512) + 1;
> > > >     } else {
> > > >     plane_blocks_per_line =
> > > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > > >     }
> > > -- 
> > > Cheers,
> > >   Lyude
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm: Make sure drm_vblank_no_hw_counter isn't abused

2016-08-08 Thread Sean Paul
On Mon, Aug 8, 2016 at 12:27 PM, Vivi, Rodrigo  wrote:
> Reviewed-by: Rodrigo Vivi 
>
> On Mon, 2016-08-08 at 18:24 +0200, Daniel Vetter wrote:
>> Shouldn't be possible since everyone kzallocs this, but better safe
>> than sorry. Random drive-by-idea really.
>>
>> Cc: Rodrigo Vivi 
>> Signed-off-by: Daniel Vetter 


Applied to drm-misc

>> ---
>>  drivers/gpu/drm/drm_irq.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index f5a9f8cef360..10611a936059 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -1795,6 +1795,7 @@ EXPORT_SYMBOL(drm_crtc_handle_vblank);
>>   */
>>  u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int
>> pipe)
>>  {
>> + WARN_ON_ONCE(dev->max_vblank_count != 0);
>>   return 0;
>>  }
>>  EXPORT_SYMBOL(drm_vblank_no_hw_counter);
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 06:25:49PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > > 
> > > Reviewed-by: Lyude 
> > 
> > Merged to dinq.  Thanks for the quick review.
> 
> Regression? This patch makes my SKL machine fail any modesets. I now
> boot to a blinking screen where X keeps trying to start and fails.

-intel has been fixing up failed multi-CRTC modesets since seemingly
forever on skl, that fail due to WM being exceeded. And why would
modesetting even be trying to use a non-tiled framebuffer?
-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] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

2016-08-08 Thread Zanoni, Paulo R
Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > 
> > Reviewed-by: Lyude 
> 
> Merged to dinq.  Thanks for the quick review.

Regression? This patch makes my SKL machine fail any modesets. I now
boot to a blinking screen where X keeps trying to start and fails.

Xorg.0.log gives me:
[   273.512] (EE) modeset(0): failed to set mode: Invalid argument


On the dmesg side, these are the more suspicious messages:

[  273.583659] [drm:skl_compute_plane_wm] Requested display
configuration exceeds system watermark limitations
[  273.583663] [drm:skl_compute_plane_wm] Plane 1.0: blocks required =
4/0, lines required = 1/31


I tried applying Lyude's series to nightly to see if it fixes
something, but it looks like patch 2 doesn't apply.

> 
> 
> Matt
> 
> > 
> > 
> > On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote:
> > > 
> > > The bspec was updated a couple weeks ago to add an extra block
> > > per
> > > line
> > > to plane watermark calculations for linear pixel formats.
> > > 
> > > Bspec update 115327 description:
> > >   "Gen9+ - Updated the plane blocks per line calculation for
> > > linear
> > >   cases. Adds +1 for all linear cases to handle the non-block
> > > aligned
> > >   stride cases."
> > > 
> > > Cc: Lyude 
> > > Signed-off-by: Matt Roper 
> > > ---
> > >  drivers/gpu/drm/i915/intel_pm.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 4317cdf..6bd352a 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3352,6 +3352,8 @@ static uint32_t skl_wm_method2(uint32_t
> > > pixel_rate, uint32_t pipe_htotal,
> > >   plane_bytes_per_line *= 4;
> > >   plane_blocks_per_line =
> > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > >   plane_blocks_per_line /= 4;
> > > + } else if (tiling == DRM_FORMAT_MOD_NONE) {
> > > + plane_blocks_per_line =
> > > DIV_ROUND_UP(plane_bytes_per_line, 512) + 1;
> > >   } else {
> > >   plane_blocks_per_line =
> > > DIV_ROUND_UP(plane_bytes_per_line, 512);
> > >   }
> > -- 
> > Cheers,
> > Lyude
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Ro.CI.BAT: success for drm: Make sure drm_vblank_no_hw_counter isn't abused

2016-08-08 Thread Patchwork
== Series Details ==

Series: drm: Make sure drm_vblank_no_hw_counter isn't abused
URL   : https://patchwork.freedesktop.org/series/10800/
State : success

== Summary ==

Series 10800v1 drm: Make sure drm_vblank_no_hw_counter isn't abused
http://patchwork.freedesktop.org/api/1.0/series/10800/revisions/1/mbox


fi-hsw-i7-4770k  total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
fi-kbl-qkkr  total:107  pass:84   dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-i5-6260u  total:107  pass:98   dwarn:0   dfail:0   fail:0   skip:8  
fi-skl-i7-6700k  total:107  pass:84   dwarn:0   dfail:0   fail:0   skip:22 
fi-snb-i7-2600   total:107  pass:77   dwarn:0   dfail:0   fail:0   skip:29 
ro-bdw-i5-5250u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5557U  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5600u  total:107  pass:79   dwarn:0   dfail:0   fail:0   skip:27 
ro-bsw-n3050 total:240  pass:195  dwarn:0   dfail:0   fail:3   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:107  pass:87   dwarn:0   dfail:0   fail:0   skip:19 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:107  pass:80   dwarn:0   dfail:0   fail:0   skip:26 
ro-skl3-i5-6260u total:107  pass:98   dwarn:0   dfail:0   fail:0   skip:8  
ro-hsw-i7-4770r failed to connect after reboot
ro-ivb2-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1768/

8ca71ca drm-intel-nightly: 2016y-08m-08d-09h-02m-24s UTC integration manifest
d414037 drm: Make sure drm_vblank_no_hw_counter isn't abused

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


Re: [Intel-gfx] [PATCH] drm: Make sure drm_vblank_no_hw_counter isn't abused

2016-08-08 Thread Vivi, Rodrigo
Reviewed-by: Rodrigo Vivi 

On Mon, 2016-08-08 at 18:24 +0200, Daniel Vetter wrote:
> Shouldn't be possible since everyone kzallocs this, but better safe
> than sorry. Random drive-by-idea really.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index f5a9f8cef360..10611a936059 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1795,6 +1795,7 @@ EXPORT_SYMBOL(drm_crtc_handle_vblank);
>   */
>  u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int
> pipe)
>  {
> + WARN_ON_ONCE(dev->max_vblank_count != 0);
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_vblank_no_hw_counter);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm: Make sure drm_vblank_no_hw_counter isn't abused

2016-08-08 Thread Daniel Vetter
Shouldn't be possible since everyone kzallocs this, but better safe
than sorry. Random drive-by-idea really.

Cc: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f5a9f8cef360..10611a936059 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1795,6 +1795,7 @@ EXPORT_SYMBOL(drm_crtc_handle_vblank);
  */
 u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe)
 {
+   WARN_ON_ONCE(dev->max_vblank_count != 0);
return 0;
 }
 EXPORT_SYMBOL(drm_vblank_no_hw_counter);
-- 
2.8.1

___
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: Drop reference to current state wait req as soon as it goes unused

2016-08-08 Thread Keith Packard
Daniel Vetter  writes:

> We still need to clean up the reference in case of failure, which
> means latest in intel_plane_destroy_state(). Also hanging onto a
> request isn't that evil really, why can't we just only clean up in the
> destroy function?

Sticking a cleanup there as well is good insurance, but it seems like a
reasonable policy to drop references when values go 'out of scope' as
they do in cleanup_plane_fb. But, you're right, we only *need* to drop
the reference in the destroy function, it's just that the state hangs
around until the next mode setting operation, which is likely to be days
away.

-- 
-keith


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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop reference to current state wait req as soon as it goes unused

2016-08-08 Thread Daniel Vetter
On Mon, Aug 8, 2016 at 1:23 PM, Maarten Lankhorst
 wrote:
> There are two paths into intel_cleanup_plane_fb, the normal completion
> path and the failure path.
>
> In the failure case, intel_cleanup_plane_fb is called before
> drm_atomic_helper_swap_state, so any wait_req reference made in
> intel_prepare_plane_fb will be in old_intel_state->wait_req.
>
> In the normal completion path, wait_req is not freed until
> the next commit, which is no longer used after waiting.
>
> Free it as soon as possible, so we don't hold on to it indefinitely.
>
> Signed-off-by: Maarten Lankhorst 
> Cc: Keith Packard 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Fixes: 849782575325 ("drm/i915: cleanup_plane_fb: also drop reference to 
> current state wait_req")

We still need to clean up the reference in case of failure, which
means latest in intel_plane_destroy_state(). Also hanging onto a
request isn't that evil really, why can't we just only clean up in the
destroy function?
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f56707289615..e72ad97998a4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13754,6 +13754,8 @@ static void intel_atomic_commit_tail(struct 
> drm_atomic_state *state)
> /* EIO should be eaten, and we can't get interrupted in the
>  * worker, and blocking commits have waited already. */
> WARN_ON(ret);
> +
> +   i915_gem_request_assign(_plane_state->wait_req, NULL);
> }
>
> if (!state->legacy_cursor_update)
> @@ -14190,7 +14192,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
>const struct drm_plane_state *old_state)
>  {
> struct drm_device *dev = plane->dev;
> -   struct intel_plane_state *intel_state = 
> to_intel_plane_state(plane->state);
> struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
> struct intel_plane_state *old_intel_state =
> to_intel_plane_state(old_state);
> @@ -14199,7 +14200,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
> !INTEL_INFO(dev)->cursor_needs_physical))
> intel_unpin_fb_obj(old_state->fb, old_state->rotation);
>
> -   i915_gem_request_assign(_state->wait_req, NULL);
> i915_gem_request_assign(_intel_state->wait_req, NULL);
>  }
>
> --
> 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
+41 (0) 79 365 57 48 - 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: Move common seqno reset to intel_engine_cs.c

2016-08-08 Thread Matthew Auld
On 8 August 2016 at 11:15, Chris Wilson  wrote:
> On Mon, Aug 08, 2016 at 10:40:35AM +0100, Matthew Auld wrote:
>> In which header does the prototype for intel_engine_init_seqno now exist?
>
> Same as before, intel_ringbuffer.h. We haven't yet decided upon
> splitting that between engine submission and actual ring operations yet.
Ok.
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/5] drm/i915: debugfs spring cleaning

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 04:20:01PM +0300, David Weinehall wrote:
> @@ -136,13 +140,14 @@ static void
>  describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
>  {
>   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> + struct drm_device *dev = _priv->drm;
>   struct intel_engine_cs *engine;
>   struct i915_vma *vma;
>   unsigned int frontbuffer_bits;
>   int pin_count = 0;
>   enum intel_engine_id id;
>  
> - lockdep_assert_held(>base.dev->struct_mutex);
> + lockdep_assert_held(>struct_mutex);

This is not a good tradeoff however. lockdep_assert_held() is
conditional code that should be compiled out,

>  
>   seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %02x %02x [ ",
>  >base,
> @@ -157,13 +162,13 @@ describe_obj(struct seq_file *m, struct 
> drm_i915_gem_object *obj)
>   for_each_engine_id(engine, dev_priv, id)
>   seq_printf(m, "%x ",
>  i915_gem_active_get_seqno(>last_read[id],
> -  
> >base.dev->struct_mutex));
> +  >struct_mutex));

Same again here.

>   seq_printf(m, "] %x %x%s%s%s",
>  i915_gem_active_get_seqno(>last_write,
> -  >base.dev->struct_mutex),
> +  >struct_mutex),
>  i915_gem_active_get_seqno(>last_fence,
> -  >base.dev->struct_mutex),
> -i915_cache_level_str(to_i915(obj->base.dev), 
> obj->cache_level),
> +  >struct_mutex),
> +i915_cache_level_str(dev_priv, obj->cache_level),
>  obj->dirty ? " dirty" : "",
>  obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
>   if (obj->base.name)
> @@ -201,7 +206,7 @@ describe_obj(struct seq_file *m, struct 
> drm_i915_gem_object *obj)
>   }
>  
>   engine = i915_gem_active_get_engine(>last_write,
> - >base.dev->struct_mutex);
> + >struct_mutex);

and again.

I'm quite happy with dev_priv->drm and need a strong argument to
introduce dev = _priv->drm locals. dev_priv->drm should avoid the
need for the compiler to emit any locals should they go out of scope.
-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 4/5] drm/i915: pdev cleanup

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 04:20:00PM +0300, David Weinehall wrote:
> In an effort to simplify things for a future push of dev_priv instead
> of dev wherever possible, always take pdev via dev_priv where
> feasible, eliminating the direct access from dev. Right now this
> only eliminates a few cases of dev, but it also obviates that we pass
> dev into a lot of functions where dev_priv would be the more obvious
> choice.
> 
> Signed-off-by: David Weinehall 

struct pci_dev *pdev improves consistency and pdev tends to be used
frequently within functions, so
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 3/5] drm/i915: sysfs spring cleaning

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 04:19:59PM +0300, David Weinehall wrote:
> -static inline struct drm_minor *kdev_to_drm_minor(struct device *kdev)
> +static inline struct drm_i915_private *kdev_to_i915_dm(struct device *kdev)

Grumble.

What is i915_dm?

minor_kdev_to_i915()
kdev_minor_to_i915()

The latter I guess.

Otherwise, looks good.
-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 2/5] drm/i915: Consistent struct device * naming

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 04:19:58PM +0300, David Weinehall wrote:
> We currently have a mix of struct device *device, struct device *kdev,
> and struct device *dev (the latter forcing us to refer to
> struct drm_device as something else than the normal dev).
> 
> To simplify things, always use kdev when referring to struct device.
> 
> While at it make dev_to_drm_minor() an inline function and
> for consistency rename it kdev_to_drm_minor().
> 
> Signed-off-by: David Weinehall 
Reviewed-by: Chris Wilson 
-Chris

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


Re: [Intel-gfx] [PATCH 1/5] drm/i915: Cosmetic fixes in i915_drv.h

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 04:19:57PM +0300, David Weinehall wrote:
> Fix minor whitespace issues plus a typo in i915_drv.h.
> 
> Signed-off-by: David Weinehall 
Reviewed-by: Chris Wilson 
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Finally fix watermarks (rev7)

2016-08-08 Thread Patchwork
== Series Details ==

Series: Finally fix watermarks (rev7)
URL   : https://patchwork.freedesktop.org/series/10276/
State : failure

== Summary ==

  CC [M]  drivers/net/ethernet/intel/e1000e/phy.o
  CC [M]  drivers/net/ethernet/realtek/r8169.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  LD  drivers/net/ethernet/broadcom/genet/built-in.o
  CC [M]  drivers/net/ethernet/broadcom/genet/bcmgenet.o
  CC [M]  drivers/net/ethernet/intel/e1000e/param.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ethtool.o
  CC [M]  drivers/net/usb/cdc_ether.o
  CC [M]  drivers/net/ethernet/intel/e1000e/netdev.o
  CC [M]  drivers/net/usb/cdc_eem.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ptp.o
  LD  drivers/net/ethernet/synopsys/built-in.o
  CC [M]  drivers/net/usb/smsc75xx.o
  CC [M]  drivers/net/ethernet/broadcom/genet/bcmmii.o
  CC [M]  drivers/net/ethernet/broadcom/genet/bcmgenet_wol.o
  CC [M]  drivers/net/usb/smsc95xx.o
  CC [M]  drivers/net/usb/mcs7830.o
  CC [M]  drivers/net/usb/usbnet.o
  CC [M]  drivers/net/usb/cdc_ncm.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:975: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/CI_Patchwork_build_2256

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


[Intel-gfx] ✗ Ro.CI.BAT: failure for Finally fix watermarks (rev7)

2016-08-08 Thread Patchwork
== Series Details ==

Series: Finally fix watermarks (rev7)
URL   : https://patchwork.freedesktop.org/series/10276/
State : failure

== Summary ==

Applying: drm/i915/skl: Add support for the SAGV, fix underrun hangs
Applying: drm/i915/skl: Update DDB values atomically with wms/plane attrs
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_display.c
M   drivers/gpu/drm/i915/intel_drv.h
M   drivers/gpu/drm/i915/intel_pm.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_pm.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_pm.c
Auto-merging drivers/gpu/drm/i915/intel_drv.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_drv.h
Auto-merging drivers/gpu/drm/i915/intel_display.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_display.c
error: Failed to merge in the changes.
Patch failed at 0002 drm/i915/skl: Update DDB values atomically with wms/plane 
attrs
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] [PATCH v9] drm/i915/skl: Update DDB values atomically with wms/plane attrs

2016-08-08 Thread Lyude
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.

The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.

The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:

We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:

|   A   |   B   |xxx|

Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.

1. Flush pipes with new allocation contained into old space. None
   apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
   previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
   giving us the following update order: A, B

This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.

As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().

This long overdue patch fixes the rest of the underruns on Skylake.

Changes since v1:
 - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
 - Use the method for updating CRTCs that Ville suggested
 - In skl_update_wm(), only copy the watermarks for the crtc that was
   passed to us
Changes since v3:
 - Small comment fix in skl_ddb_allocation_overlaps()

Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]

Testcase: kms_cursor_legacy
Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 100 +++--
 drivers/gpu/drm/i915/intel_drv.h |   7 ++
 drivers/gpu/drm/i915/intel_pm.c  | 207 +--
 3 files changed, 144 insertions(+), 170 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 980b6fd..ad5f6e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12903,16 +12903,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
  hw_entry->start, hw_entry->end);
}
 
-   /* cursor */
-   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
-   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
-
-   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+   if (intel_crtc->cursor_addr) {
+   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
+   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
+
+   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+   }
}
 }
 
@@ -13664,6 +13671,72 @@ static void intel_update_crtcs(struct drm_atomic_state 
*state,
}
 }
 
+static void skl_update_crtcs(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask)
+{
+   struct drm_device *dev = state->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   

[Intel-gfx] [PATCH v9] drm/i915/skl: Update DDB values atomically with wms/plane attrs

2016-08-08 Thread Lyude
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.

The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.

The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:

We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:

|   A   |   B   |xxx|

Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.

1. Flush pipes with new allocation contained into old space. None
   apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
   previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
   giving us the following update order: A, B

This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.

As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().

This long overdue patch fixes the rest of the underruns on Skylake.

Changes since v1:
 - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
 - Use the method for updating CRTCs that Ville suggested
 - In skl_update_wm(), only copy the watermarks for the crtc that was
   passed to us
Changes since v3:
 - Small comment fix in skl_ddb_allocation_overlaps()

Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]

Testcase: kms_cursor_legacy
Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 100 +++--
 drivers/gpu/drm/i915/intel_drv.h |   7 ++
 drivers/gpu/drm/i915/intel_pm.c  | 207 +--
 3 files changed, 144 insertions(+), 170 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 980b6fd..ad5f6e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12903,16 +12903,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
  hw_entry->start, hw_entry->end);
}
 
-   /* cursor */
-   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
-   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
-
-   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+   if (intel_crtc->cursor_addr) {
+   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
+   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
+
+   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+   }
}
 }
 
@@ -13664,6 +13671,72 @@ static void intel_update_crtcs(struct drm_atomic_state 
*state,
}
 }
 
+static void skl_update_crtcs(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask)
+{
+   struct drm_device *dev = state->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   

[Intel-gfx] ✗ Ro.CI.BAT: failure for Various cleanup (rev2)

2016-08-08 Thread Patchwork
== Series Details ==

Series: Various cleanup (rev2)
URL   : https://patchwork.freedesktop.org/series/10458/
State : failure

== Summary ==

Series 10458v2 Various cleanup
http://patchwork.freedesktop.org/api/1.0/series/10458/revisions/2/mbox

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-i5-6260u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-byt-n2820)

fi-hsw-i7-4770k  total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
fi-kbl-qkkr  total:107  pass:84   dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-i5-6260u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
fi-skl-i7-6700k  total:107  pass:84   dwarn:0   dfail:0   fail:0   skip:22 
fi-snb-i7-2600   total:107  pass:77   dwarn:0   dfail:0   fail:0   skip:29 
ro-bdw-i5-5250u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5557U  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5600u  total:107  pass:79   dwarn:0   dfail:0   fail:0   skip:27 
ro-byt-n2820 total:240  pass:196  dwarn:0   dfail:0   fail:4   skip:40 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:107  pass:80   dwarn:0   dfail:0   fail:0   skip:26 
ro-skl3-i5-6260u total:107  pass:98   dwarn:0   dfail:0   fail:0   skip:8  
ro-bsw-n3050 failed to connect after reboot
ro-hsw-i3-4010u failed to connect after reboot
ro-hsw-i7-4770r failed to connect after reboot
ro-ivb2-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1765/

8ca71ca drm-intel-nightly: 2016y-08m-08d-09h-02m-24s UTC integration manifest
7dc3805 drm/i915: debugfs spring cleaning
4a7d66a drm/i915: pdev cleanup
8c3ed85 drm/i915: sysfs spring cleaning
4d0cde8 drm/i915: Consistent struct device * naming
64b0d95 drm/i915: Cosmetic fixes in i915_drv.h

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


[Intel-gfx] [PATCH 1/5] drm/i915: Cosmetic fixes in i915_drv.h

2016-08-08 Thread David Weinehall
Fix minor whitespace issues plus a typo in i915_drv.h.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c36d17659ebe..e71f334a46bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2552,7 +2552,7 @@ struct drm_i915_cmd_table {
BUILD_BUG(); \
__p; \
 })
-#define INTEL_INFO(p)  (&__I915__(p)->info)
+#define INTEL_INFO(p)  (&__I915__(p)->info)
 #define INTEL_GEN(p)   (INTEL_INFO(p)->gen)
 #define INTEL_DEVID(p) (INTEL_INFO(p)->device_id)
 
@@ -2846,7 +2846,7 @@ extern int i915_suspend_switcheroo(struct drm_device 
*dev, pm_message_t state);
 extern int i915_resume_switcheroo(struct drm_device *dev);
 
 int intel_sanitize_enable_ppgtt(struct drm_i915_private *dev_priv,
-   int enable_ppgtt);
+   int enable_ppgtt);
 
 bool intel_sanitize_semaphores(struct drm_i915_private *dev_priv, int value);
 
@@ -3754,7 +3754,7 @@ __raw_write(64, q)
 #undef __raw_write
 
 /* These are untraced mmio-accessors that are only valid to be used inside
- * criticial sections inside IRQ handlers where forcewake is explicitly
+ * critical sections inside IRQ handlers where forcewake is explicitly
  * controlled.
  * Think twice, and think again, before using these.
  * Note: Should only be used between intel_uncore_forcewake_irqlock() and
-- 
2.8.1

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


[Intel-gfx] [PATCH 0/5] Various cleanup

2016-08-08 Thread David Weinehall
This patch series aims to do some cleanup of our driver.
Patch 1, 2, and 4 should be fairly non-controversial.
Patch 3 and 5 does major cleanups of i915_sysfs and i915_debugfs,
respectively. Due to the nature of these patches they are rather
big, but that's mainly because they change the parameter passed
to macros that are used a lot.

While the secondary benefits of this patch series (the primary
of course being slightly cleaner code) might be a bit opaque,
a move to always passing dev_priv to our feature macros
(and thus allowing us to make those macros non-polymorphic)
will save more than 30kB.

That's still a bit down the road though, but I've got a full
patch series to accomplish this in a fairly straightforward
manner.

This submission supersedes the previous one (from the 1st of August);
it drops one patch, and adds two others.

David Weinehall (5):
  drm/i915: Cosmetic fixes in i915_drv.h
  drm/i915: Consistent struct device * naming
  drm/i915: sysfs spring cleaning
  drm/i915: pdev cleanup
  drm/i915: debugfs spring cleaning

 drivers/gpu/drm/i915/i915_debugfs.c | 704 ++--
 drivers/gpu/drm/i915/i915_drv.c | 157 +++
 drivers/gpu/drm/i915/i915_drv.h |  22 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  10 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  17 +-
 drivers/gpu/drm/i915/i915_gpu_error.c   |   9 +-
 drivers/gpu/drm/i915/i915_suspend.c |   6 +-
 drivers/gpu/drm/i915/i915_sysfs.c   | 163 
 drivers/gpu/drm/i915/intel_audio.c  |  46 +--
 drivers/gpu/drm/i915/intel_display.c|  25 +-
 drivers/gpu/drm/i915/intel_fbdev.c  |   3 +-
 drivers/gpu/drm/i915/intel_guc_loader.c |   3 +-
 drivers/gpu/drm/i915/intel_i2c.c|   3 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |  57 +--
 drivers/gpu/drm/i915/intel_sdvo.c   |   4 +-
 15 files changed, 588 insertions(+), 641 deletions(-)

-- 
2.8.1

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


[Intel-gfx] [PATCH 3/5] drm/i915: sysfs spring cleaning

2016-08-08 Thread David Weinehall
Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.

The main use of kdev_to_drm_minor() was as an intermediate step
when extracting dev_priv, so make that helper do that bit too,
and rename it kdev_to_i915_dm() (to differentiate it from
kdev_to_i915(), which goes about this in a different, non-compatible,
way).

All calls to INTEL_INFO()->gen have been replaced with
INTEL_GEN().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c   |   4 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_sysfs.c | 148 +-
 3 files changed, 69 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e324cd0dbfa9..5e9325e4b1e5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1131,7 +1131,7 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
-   i915_setup_sysfs(dev);
+   i915_setup_sysfs(dev_priv);
} else
DRM_ERROR("Failed to register driver for userspace access!\n");
 
@@ -1168,7 +1168,7 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
acpi_video_unregister();
intel_opregion_unregister(dev_priv);
 
-   i915_teardown_sysfs(_priv->drm);
+   i915_teardown_sysfs(dev_priv);
i915_debugfs_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4975de75e2a1..751f2b4d7b4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3531,8 +3531,8 @@ extern int i915_save_state(struct drm_device *dev);
 extern int i915_restore_state(struct drm_device *dev);
 
 /* i915_sysfs.c */
-void i915_setup_sysfs(struct drm_device *dev_priv);
-void i915_teardown_sysfs(struct drm_device *dev_priv);
+void i915_setup_sysfs(struct drm_i915_private *dev_priv);
+void i915_teardown_sysfs(struct drm_i915_private *dev_priv);
 
 /* intel_i2c.c */
 extern int intel_setup_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 05cb95bf2f4b..87368202f3c1 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -32,16 +32,16 @@
 #include "intel_drv.h"
 #include "i915_drv.h"
 
-static inline struct drm_minor *kdev_to_drm_minor(struct device *kdev)
+static inline struct drm_i915_private *kdev_to_i915_dm(struct device *kdev)
 {
-   return dev_get_drvdata(kdev);
+   struct drm_minor *minor = dev_get_drvdata(kdev);
+   return to_i915(minor->dev);
 }
 
 #ifdef CONFIG_PM
-static u32 calc_residency(struct drm_device *dev,
+static u32 calc_residency(struct drm_i915_private *dev_priv,
  i915_reg_t reg)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
u64 raw_time; /* 32b value may overflow during fixed point math */
u64 units = 128ULL, div = 10ULL;
u32 ret;
@@ -52,13 +52,13 @@ static u32 calc_residency(struct drm_device *dev,
intel_runtime_pm_get(dev_priv);
 
/* On VLV and CHV, residency time is in CZ units rather than 1.28us */
-   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
units = 1;
div = dev_priv->czclk_freq;
 
if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
units <<= 8;
-   } else if (IS_BROXTON(dev)) {
+   } else if (IS_BROXTON(dev_priv)) {
units = 1;
div = 1200; /* 833.33ns */
}
@@ -79,32 +79,32 @@ show_rc6_mask(struct device *kdev, struct device_attribute 
*attr, char *buf)
 static ssize_t
 show_rc6_ms(struct device *kdev, struct device_attribute *attr, char *buf)
 {
-   struct drm_minor *dminor = dev_get_drvdata(kdev);
-   u32 rc6_residency = calc_residency(dminor->dev, GEN6_GT_GFX_RC6);
+   struct drm_i915_private *dev_priv = kdev_to_i915_dm(kdev);
+   u32 rc6_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6);
return snprintf(buf, PAGE_SIZE, "%u\n", rc6_residency);
 }
 
 static ssize_t
 show_rc6p_ms(struct device *kdev, struct device_attribute *attr, char *buf)
 {
-   struct drm_minor *dminor = kdev_to_drm_minor(kdev);
-   u32 rc6p_residency = calc_residency(dminor->dev, GEN6_GT_GFX_RC6p);
+   struct drm_i915_private *dev_priv = kdev_to_i915_dm(kdev);
+   u32 rc6p_residency = calc_residency(dev_priv, GEN6_GT_GFX_RC6p);
return snprintf(buf, PAGE_SIZE, "%u\n", rc6p_residency);
 }
 
 static ssize_t
 

[Intel-gfx] [PATCH 5/5] drm/i915: debugfs spring cleaning

2016-08-08 Thread David Weinehall
Just like with sysfs, we do some major overhaul.

Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.

All calls to INTEL_INFO()->gen have been replaced with
INTEL_GEN().

We want access to to_i915(node->minor->dev) in a lot of places,
so add the node_to_i915() helper to accomodate for this.

Finally, we have quite a few cases where we get a void * pointer,
and need to cast it to drm_device *, only to run to_i915() on it.
Add cast_to_i915() to do this.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 699 
 drivers/gpu/drm/i915/i915_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_drv.h |   8 +-
 3 files changed, 321 insertions(+), 388 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ad4f7178667c..6d31d35cc89b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -46,6 +46,11 @@ enum {
PINNED_LIST,
 };
 
+static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
+{
+   return to_i915(node->minor->dev);
+}
+
 /* As the drm_debugfs_init() routines are called before dev->dev_private is
  * allocated we need to hook into the minor for release. */
 static int
@@ -74,12 +79,11 @@ drm_add_fake_info_node(struct drm_minor *minor,
 
 static int i915_capabilities(struct seq_file *m, void *data)
 {
-   struct drm_info_node *node = m->private;
-   struct drm_device *dev = node->minor->dev;
-   const struct intel_device_info *info = INTEL_INFO(dev);
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   const struct intel_device_info *info = INTEL_INFO(dev_priv);
 
-   seq_printf(m, "gen: %d\n", info->gen);
-   seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev));
+   seq_printf(m, "gen: %d\n", INTEL_GEN(dev_priv));
+   seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev_priv));
 #define PRINT_FLAG(x)  seq_printf(m, #x ": %s\n", yesno(info->x))
 #define SEP_SEMICOLON ;
DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG, SEP_SEMICOLON);
@@ -136,13 +140,14 @@ static void
 describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+   struct drm_device *dev = _priv->drm;
struct intel_engine_cs *engine;
struct i915_vma *vma;
unsigned int frontbuffer_bits;
int pin_count = 0;
enum intel_engine_id id;
 
-   lockdep_assert_held(>base.dev->struct_mutex);
+   lockdep_assert_held(>struct_mutex);
 
seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %02x %02x [ ",
   >base,
@@ -157,13 +162,13 @@ describe_obj(struct seq_file *m, struct 
drm_i915_gem_object *obj)
for_each_engine_id(engine, dev_priv, id)
seq_printf(m, "%x ",
   i915_gem_active_get_seqno(>last_read[id],
-
>base.dev->struct_mutex));
+>struct_mutex));
seq_printf(m, "] %x %x%s%s%s",
   i915_gem_active_get_seqno(>last_write,
->base.dev->struct_mutex),
+>struct_mutex),
   i915_gem_active_get_seqno(>last_fence,
->base.dev->struct_mutex),
-  i915_cache_level_str(to_i915(obj->base.dev), 
obj->cache_level),
+>struct_mutex),
+  i915_cache_level_str(dev_priv, obj->cache_level),
   obj->dirty ? " dirty" : "",
   obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
if (obj->base.name)
@@ -201,7 +206,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
}
 
engine = i915_gem_active_get_engine(>last_write,
-   >base.dev->struct_mutex);
+   >struct_mutex);
if (engine)
seq_printf(m, " (%s)", engine->name);
 
@@ -215,8 +220,8 @@ static int i915_gem_object_list_info(struct seq_file *m, 
void *data)
struct drm_info_node *node = m->private;
uintptr_t list = (uintptr_t) node->info_ent->data;
struct list_head *head;
-   struct drm_device *dev = node->minor->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = node_to_i915(node);
+   struct drm_device *dev = _priv->drm;
struct i915_ggtt *ggtt = _priv->ggtt;
struct i915_vma *vma;
u64 total_obj_size, total_gtt_size;
@@ -274,9 +279,8 @@ static int obj_rank_by_stolen(void *priv,
 
 static int i915_gem_stolen_list_info(struct seq_file *m, void *data)
 {
-   

[Intel-gfx] [PATCH 2/5] drm/i915: Consistent struct device * naming

2016-08-08 Thread David Weinehall
We currently have a mix of struct device *device, struct device *kdev,
and struct device *dev (the latter forcing us to refer to
struct drm_device as something else than the normal dev).

To simplify things, always use kdev when referring to struct device.

While at it make dev_to_drm_minor() an inline function and
for consistency rename it kdev_to_drm_minor().

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c | 96 -
 drivers/gpu/drm/i915/i915_drv.h |  4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  6 +--
 drivers/gpu/drm/i915/i915_sysfs.c   | 65 +++---
 drivers/gpu/drm/i915/intel_audio.c  | 46 
 drivers/gpu/drm/i915/intel_runtime_pm.c | 37 +++--
 6 files changed, 128 insertions(+), 126 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8cfc264ec9f6..e324cd0dbfa9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -77,7 +77,7 @@ __i915_printk(struct drm_i915_private *dev_priv, const char 
*level,
  const char *fmt, ...)
 {
static bool shown_bug_once;
-   struct device *dev = dev_priv->drm.dev;
+   struct device *kdev = dev_priv->drm.dev;
bool is_error = level[1] <= KERN_ERR[1];
bool is_debug = level[1] == KERN_DEBUG[1];
struct va_format vaf;
@@ -91,11 +91,11 @@ __i915_printk(struct drm_i915_private *dev_priv, const char 
*level,
vaf.fmt = fmt;
vaf.va = 
 
-   dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
+   dev_printk(level, kdev, "[" DRM_NAME ":%ps] %pV",
   __builtin_return_address(0), );
 
if (is_error && !shown_bug_once) {
-   dev_notice(dev, "%s", FDO_BUG_MSG);
+   dev_notice(kdev, "%s", FDO_BUG_MSG);
shown_bug_once = true;
}
 
@@ -1460,9 +1460,9 @@ out:
return error;
 }
 
-static int i915_drm_suspend_late(struct drm_device *drm_dev, bool hibernation)
+static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
 {
-   struct drm_i915_private *dev_priv = to_i915(drm_dev);
+   struct drm_i915_private *dev_priv = to_i915(dev);
bool fw_csr;
int ret;
 
@@ -1496,7 +1496,7 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
goto out;
}
 
-   pci_disable_device(drm_dev->pdev);
+   pci_disable_device(dev->pdev);
/*
 * During hibernation on some platforms the BIOS may try to access
 * the device even though it's already in D3 and hang the machine. So
@@ -1510,7 +1510,7 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
 * Acer Aspire 1830T
 */
if (!(hibernation && INTEL_INFO(dev_priv)->gen < 6))
-   pci_set_power_state(drm_dev->pdev, PCI_D3hot);
+   pci_set_power_state(dev->pdev, PCI_D3hot);
 
dev_priv->suspended_to_idle = suspend_to_idle(dev_priv);
 
@@ -1807,25 +1807,25 @@ error:
return ret;
 }
 
-static int i915_pm_suspend(struct device *dev)
+static int i915_pm_suspend(struct device *kdev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct drm_device *drm_dev = pci_get_drvdata(pdev);
+   struct pci_dev *pdev = to_pci_dev(kdev);
+   struct drm_device *dev = pci_get_drvdata(pdev);
 
-   if (!drm_dev) {
-   dev_err(dev, "DRM not initialized, aborting suspend.\n");
+   if (!dev) {
+   dev_err(kdev, "DRM not initialized, aborting suspend.\n");
return -ENODEV;
}
 
-   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
 
-   return i915_drm_suspend(drm_dev);
+   return i915_drm_suspend(dev);
 }
 
-static int i915_pm_suspend_late(struct device *dev)
+static int i915_pm_suspend_late(struct device *kdev)
 {
-   struct drm_device *drm_dev = _to_i915(dev)->drm;
+   struct drm_device *dev = _to_i915(kdev)->drm;
 
/*
 * We have a suspend ordering issue with the snd-hda driver also
@@ -1836,57 +1836,57 @@ static int i915_pm_suspend_late(struct device *dev)
 * FIXME: This should be solved with a special hdmi sink device or
 * similar so that power domains can be employed.
 */
-   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
+   if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
 
-   return i915_drm_suspend_late(drm_dev, false);
+   return i915_drm_suspend_late(dev, false);
 }
 
-static int i915_pm_poweroff_late(struct device *dev)
+static int i915_pm_poweroff_late(struct device *kdev)
 {
-   struct drm_device *drm_dev = _to_i915(dev)->drm;
+   struct drm_device *dev = _to_i915(kdev)->drm;
 
-   if 

[Intel-gfx] [PATCH 4/5] drm/i915: pdev cleanup

2016-08-08 Thread David Weinehall
In an effort to simplify things for a future push of dev_priv instead
of dev wherever possible, always take pdev via dev_priv where
feasible, eliminating the direct access from dev. Right now this
only eliminates a few cases of dev, but it also obviates that we pass
dev into a lot of functions where dev_priv would be the more obvious
choice.

Signed-off-by: David Weinehall 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  5 +--
 drivers/gpu/drm/i915/i915_drv.c | 59 +++--
 drivers/gpu/drm/i915/i915_gem_gtt.c |  4 ++-
 drivers/gpu/drm/i915/i915_gem_stolen.c  | 17 +-
 drivers/gpu/drm/i915/i915_gpu_error.c   |  9 ++---
 drivers/gpu/drm/i915/i915_suspend.c |  6 ++--
 drivers/gpu/drm/i915/intel_display.c| 25 +-
 drivers/gpu/drm/i915/intel_fbdev.c  |  3 +-
 drivers/gpu/drm/i915/intel_guc_loader.c |  3 +-
 drivers/gpu/drm/i915/intel_i2c.c|  3 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 30 +
 drivers/gpu/drm/i915/intel_sdvo.c   |  4 ++-
 12 files changed, 99 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9bd41581b592..ad4f7178667c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2787,6 +2787,7 @@ static int i915_runtime_pm_status(struct seq_file *m, 
void *unused)
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
 
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
@@ -2801,8 +2802,8 @@ static int i915_runtime_pm_status(struct seq_file *m, 
void *unused)
seq_printf(m, "Device Power Management (CONFIG_PM) disabled\n");
 #endif
seq_printf(m, "PCI device power state: %s [%d]\n",
-  pci_power_name(dev_priv->drm.pdev->current_state),
-  dev_priv->drm.pdev->current_state);
+  pci_power_name(pdev->current_state),
+  pdev->current_state);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5e9325e4b1e5..7ea6b8e64681 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -232,6 +232,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
drm_i915_getparam_t *param = data;
int value;
 
@@ -242,10 +243,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
/* Reject all old ums/dri params. */
return -ENODEV;
case I915_PARAM_CHIPSET_ID:
-   value = dev->pdev->device;
+   value = pdev->device;
break;
case I915_PARAM_REVISION:
-   value = dev->pdev->revision;
+   value = pdev->revision;
break;
case I915_PARAM_HAS_GEM:
value = 1;
@@ -516,7 +517,7 @@ static void i915_switcheroo_set_state(struct pci_dev *pdev, 
enum vga_switcheroo_
pr_info("switched on\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
/* i915 resume handler doesn't set to D0 */
-   pci_set_power_state(dev->pdev, PCI_D0);
+   pci_set_power_state(pdev, PCI_D0);
i915_resume_switcheroo(dev);
dev->switch_power_state = DRM_SWITCH_POWER_ON;
} else {
@@ -585,6 +586,7 @@ static void i915_gem_fini(struct drm_device *dev)
 static int i915_load_modeset_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct pci_dev *pdev = dev_priv->drm.pdev;
int ret;
 
if (i915_inject_load_failure())
@@ -601,13 +603,13 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * then we do not take part in VGA arbitration and the
 * vga_client_register() fails with -ENODEV.
 */
-   ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
+   ret = vga_client_register(pdev, dev, NULL, i915_vga_set_decode);
if (ret && ret != -ENODEV)
goto out;
 
intel_register_dsm_handler();
 
-   ret = vga_switcheroo_register_client(dev->pdev, _switcheroo_ops, 
false);
+   ret = vga_switcheroo_register_client(pdev, _switcheroo_ops, false);
if (ret)
goto cleanup_vga_client;
 
@@ -659,9 +661,9 @@ cleanup_irq:
 cleanup_csr:
intel_csr_ucode_fini(dev_priv);
intel_power_domains_fini(dev_priv);
-   vga_switcheroo_unregister_client(dev->pdev);
+   vga_switcheroo_unregister_client(pdev);
 cleanup_vga_client:
-   

Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

2016-08-08 Thread David Weinehall
On Mon, Aug 08, 2016 at 03:52:41PM +0300, Ville Syrjälä wrote:
> On Fri, Aug 05, 2016 at 03:45:19PM -0700, Clint Taylor wrote:
> > On 08/03/2016 06:36 AM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä 
> > >
> > > Dell UP2414Q doesn't like it when we're driving it in MST mode, and then
> > > reboot the machine. After reboot, the monitor is somehow confused and
> > > refuses to do the payload allocation:
> > >   [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 282 8
> > >   [drm:drm_dp_dpcd_write_payload] status not set after read payload table 
> > > status 0
> > > and thus we're left with a black screen until the monitor power is
> > > toggled.
> > >
> > > It seems that if we shut down things gracefully prior to rebooting, the
> > > monitor doesn't get confused like this. So let's try to shut down all
> > > the displays gracefully on reboot. The downside is that we will
> > > introduce the reboot notifier to all the modesetl locks. So if there's
> > > a locking bug around, we might not be able to reboot the machine
> > > gracefully. sysrq reboot will still work though, as it will not
> > > call the notifiers.
> > >
> > > While we do this, we can eliminate the eDP reboot notifier, which is
> > > there to shut down the panel power and make sure the firmware won't
> > > violate the panel power cycle delay post-reboot. Since we're now
> > > shutting eDP down properly, we can mostly just rip out the eDP notifier.
> > > We still need to do the panel power cycle wait though, as that would
> > > normally get postponed until the next modeset. So let's move that part
> > > into intel_panel so that other display types will get the same treatment
> > > as a bonus.
> > >
> > > The Dell UP2414Q can often get even more confused, and sometimes what
> > > you have to do is: switch to another input on the monitor, toggle the
> > > monitor power, switch the input back to the original setting. And
> > > sometimes it seems you just have to yank the power cable entirely. I'm
> > > not sure if this reboot notifier might avoid some of these other
> > > failure modes as well, but I'm pretty sure it can't hurt at least.
> > >
> > 
> > While testing this change on SKL if 2 crtc's are enabled resume from 
> > suspend is 500ms longer than a single crtc resume. Are we calling the 
> > T12 msleep(500) for non eDP panels?
> 
> Seems unlikely, unless we misdetect DP as eDP. 500ms sure sounds a lot
> for non-eDP though.

You can try this patch to get easy access to the timings to see if
they seem reasonable:


commit 7e88e096931065efebd43d844fe3bf106932a9fa
Author: David Weinehall 
Date:   Thu Jul 21 13:36:49 2016 +0300

drm/i915/debugfs: Add panel delays for eDP

The eDP backlight and panel enable/disable delays are quite
useful to know when measuring time consumed by suspend/resume,
and while the information are printed to the kernel log as debug
messages, having this information in debugfs makes things easier.

Signed-off-by: David Weinehall 

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e726b02bdb5a..282d6716d012 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5544,6 +5544,40 @@ static const struct file_operations i915_dpcd_fops = {
.release = single_release,
 };
 
+static int i915_panel_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct intel_dp *intel_dp =
+   enc_to_intel_dp(_attached_encoder(connector)->base);
+
+   if (connector->status != connector_status_connected)
+   return -ENODEV;
+
+   seq_printf(m, "Panel power up delay: %d\n",
+  intel_dp->panel_power_up_delay);
+   seq_printf(m, "Panel power down delay: %d\n",
+  intel_dp->panel_power_down_delay);
+   seq_printf(m, "Backlight on delay: %d\n",
+  intel_dp->backlight_on_delay);
+   seq_printf(m, "Backlight off delay: %d\n",
+  intel_dp->backlight_off_delay);
+
+   return 0;
+}
+
+static int i915_panel_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, i915_panel_show, inode->i_private);
+}
+
+static const struct file_operations i915_panel_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_panel_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+
 /**
  * i915_debugfs_connector_add - add i915 specific connector debugfs files
  * @connector: pointer to a registered drm_connector
@@ -5563,8 +5597,12 @@ int i915_debugfs_connector_add(struct drm_connector 
*connector)
 
if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector->connector_type == DRM_MODE_CONNECTOR_eDP)
-   debugfs_create_file("i915_dpcd", S_IRUGO, root, 

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: DP branch devices (rev7)

2016-08-08 Thread Patchwork
== Series Details ==

Series: drm/i915: DP branch devices (rev7)
URL   : https://patchwork.freedesktop.org/series/6658/
State : failure

== Summary ==

Applying: drm: Read DP branch device HW revision
fatal: sha1 information is lacking or useless (drivers/gpu/drm/drm_dp_helper.c).
error: could not build fake ancestor
Patch failed at 0001 drm: Read DP branch device HW revision
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


[Intel-gfx] [PATCH v7 4/5] drm: Update bits per component for display info

2016-08-08 Thread Mika Kahola
DisplayPort branch device may define max supported bits per
component. Update display info based on this value if bpc
is defined.

v2: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v3: Fill bpc for connector's display info in separate
drm_dp_helper function (Daniel)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 24 
 drivers/gpu/drm/i915/intel_dp.c |  3 +++
 include/drm/drm_dp_helper.h |  4 
 3 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1f36016..a2c46ed 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -514,6 +514,30 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
 
 /**
+ * drm_dp_downstream_update_max_bpc() - extract branch device max
+ *  bits per component and update
+ *  connector max bpc
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ * @connector: Connector info
+ * Returns current max bpc on success
+ */
+int drm_dp_downstream_update_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+const u8 port_cap[4],
+struct drm_connector *connector)
+{
+   if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT) {
+   int bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
+
+   if (bpc > 0)
+   connector->display_info.bpc = bpc;
+   }
+
+   return connector->display_info.bpc;
+}
+EXPORT_SYMBOL(drm_dp_downstream_update_max_bpc);
+
+/**
  * drm_dp_downstream_hw_rev() - read DP branch device HW revision
  * @aux: DisplayPort AUX channel
  *
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e990c8b..763e2f5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3985,6 +3985,9 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
uint8_t *dpcd = intel_dp->dpcd;
uint8_t type;
 
+   drm_dp_downstream_update_max_bpc(dpcd, intel_dp->downstream_ports,
+_dp->attached_connector->base);
+
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 45366aa..5491a9b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
@@ -827,6 +828,9 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
  const u8 port_cap[4]);
+int drm_dp_downstream_update_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+const u8 port_cap[4],
+struct drm_connector *connector);
 int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
 int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
 struct drm_dp_aux *aux, struct drm_dp_link *link);
-- 
1.9.1

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


[Intel-gfx] [PATCH v7 5/5] drm: Add DP branch device info on debugfs

2016-08-08 Thread Mika Kahola
Read DisplayPort branch device info from through debugfs
interface.

v2: use drm_dp_helper routines to collect data
v3: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v4: move DP branch device info to function 'intel_dp_branch_device_info()'
v5: initial step to move debugging info from intel_dp. to drm_dp_helper.c 
(Daniel)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 80 +
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +
 include/drm/drm_dp_helper.h |  2 +
 3 files changed, 84 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a2c46ed..47bbb5e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -603,6 +603,86 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char 
id[6])
 }
 EXPORT_SYMBOL(drm_dp_downstream_id);
 
+/**
+ * drm_dp_downstream_debug() - debug DP branch devices
+ * @m: pointer for debugfs file
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ * @aux: DisplayPort AUX channel
+ *
+ */
+void drm_dp_downstream_debug(struct seq_file *m, const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
+const u8 port_cap[4], struct drm_dp_aux *aux)
+{
+   struct drm_dp_link link;
+   bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DETAILED_CAP_INFO_AVAILABLE;
+   int clk;
+   int bpc;
+   char id[6];
+   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
+   bool branch_device = dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
DP_DWN_STRM_PORT_PRESENT;
+
+   seq_printf(m, "\tDP branch device present: %s\n", branch_device ? "yes" 
: "no");
+
+   if (!branch_device)
+   return;
+
+   switch (type) {
+   case DP_DS_PORT_TYPE_DP:
+   seq_printf(m, "\t\tType: DisplayPort\n");
+   break;
+   case DP_DS_PORT_TYPE_VGA:
+   seq_printf(m, "\t\tType: VGA\n");
+   break;
+   case DP_DS_PORT_TYPE_DVI:
+   seq_printf(m, "\t\tType: DVI\n");
+   break;
+   case DP_DS_PORT_TYPE_HDMI:
+   seq_printf(m, "\t\tType: HDMI\n");
+   break;
+   case DP_DS_PORT_TYPE_NON_EDID:
+   seq_printf(m, "\t\tType: others without EDID support\n");
+   break;
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   seq_printf(m, "\t\tType: DP++\n");
+   break;
+   case DP_DS_PORT_TYPE_WIRELESS:
+   seq_printf(m, "\t\tType: Wireless\n");
+   break;
+   default:
+   seq_printf(m, "\t\tType: N/A\n");
+   }
+
+   drm_dp_downstream_id(aux, id);
+   seq_printf(m, "\t\tID: %s\n", id);
+
+   if (drm_dp_downstream_hw_rev(dpcd, aux, ) == 0)
+   seq_printf(m, "\t\tHW revision: %.2d.%.2d\n", 
link.ds_hw_rev.major,
+  link.ds_hw_rev.minor);
+
+   if (drm_dp_downstream_sw_rev(dpcd, aux, ) == 0)
+   seq_printf(m, "\t\tSW revision: %.2d.%.2d\n", 
link.ds_sw_rev.major,
+  link.ds_sw_rev.minor);
+
+   if (detailed_cap_info) {
+   clk = drm_dp_downstream_max_clock(dpcd, port_cap);
+
+   if (clk > 0) {
+   if (type == DP_DS_PORT_TYPE_VGA)
+   seq_printf(m, "\t\tMax dot clock: %d kHz\n", 
clk);
+   else
+   seq_printf(m, "\t\tMax TMDS clock: %d kHz\n", 
clk);
+   }
+
+   bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
+
+   if (bpc > 0)
+   seq_printf(m, "\t\tMax bpc: %d\n", bpc);
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_debug);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 531ca02..3747f67 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2959,6 +2959,8 @@ static void intel_dp_info(struct seq_file *m,
seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
if (intel_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
intel_panel_info(m, _connector->panel);
+   drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
+   _dp->aux);
 }
 
 static void intel_hdmi_info(struct seq_file *m,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5491a9b..85123ac 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -837,6 +837,8 @@ int drm_dp_downstream_hw_rev(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 
 int drm_dp_downstream_sw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
 struct drm_dp_aux *aux, struct drm_dp_link *link);
+void drm_dp_downstream_debug(struct seq_file *m, const u8 
dpcd[DP_RECEIVER_CAP_SIZE],

[Intel-gfx] [PATCH v7 3/5] drm/i915: Check pixel rate for DP to VGA dongle

2016-08-08 Thread Mika Kahola
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.

The register defines the pixel rate divided by 8 in MP/s.

v2: DPCD read outs and computation moved to drm (Ville, Daniel)
v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
function (Daniel)
v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
v5: Use of intel_dp->downstream_ports to read out port capabilities.
Code restructuring (Ville)
v6: Move DP branch device check to drm_dp_helper.c (Daniel)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 21b04c3..e990c8b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -190,6 +190,26 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
return (max_link_clock * max_lanes * 8) / 10;
 }
 
+static int
+intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, int dotclk)
+{
+   int ds_dotclk;
+   int type;
+
+   ds_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
+   intel_dp->downstream_ports);
+
+   if (ds_dotclk == 0)
+   return dotclk;
+
+   type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+
+   if (type != DP_DS_PORT_TYPE_VGA)
+   return dotclk;
+
+   return min(dotclk, ds_dotclk);
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -199,7 +219,10 @@ intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
-   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+   int max_dotclk;
+
+   max_dotclk = intel_dp_downstream_max_dotclock(intel_dp,
+ 
to_i915(connector->dev)->max_dotclk_freq);
 
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
-- 
1.9.1

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


[Intel-gfx] [PATCH v7 0/5] drm/i915: DP branch devices

2016-08-08 Thread Mika Kahola
Prep work for DP branch device handling

This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards

 - DP to VGA
 - DP to DVI
 - DP to HDMI
 - DP++ dual mode
 - Wireless WiGig
 
DPCD register defines max pixel rate for VGA dongles. This
check is carried out during mode validation. 

[1] git://github.com/mkahola/drm-intel-mika.git dp_branch_device

v2: DPCD register read outs moved to drm (Ville, Daniel)
v3: Max pixel rate computation moved to drm (Daniel)
v4: Use of drm_dp_helper routines to collect data (Ville)
v5: Remove duplicate code and unnecessary functions from drm_dp_helper (Ville)
v6: Rebase and i915_debugfs cleanup
v7: Structure cleanups and initial step to move DP debugging info to 
drm_dp_helpers

Mika Kahola (5):
  drm: Read DP branch device HW revision
  drm: Read DP branch device SW revision
  drm/i915: Check pixel rate for DP to VGA dongle
  drm: Update bits per component for display info
  drm: Add DP branch device info on debugfs

 drivers/gpu/drm/drm_dp_helper.c | 158 
 drivers/gpu/drm/i915/i915_debugfs.c |   2 +
 drivers/gpu/drm/i915/intel_dp.c |  28 ++-
 drivers/gpu/drm/i915/intel_drv.h|   1 +
 include/drm/drm_dp_helper.h |  20 +
 5 files changed, 208 insertions(+), 1 deletion(-)

-- 
1.9.1

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


[Intel-gfx] [PATCH v7 2/5] drm: Read DP branch device SW revision

2016-08-08 Thread Mika Kahola
SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x50A.

v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 27 +++
 include/drm/drm_dp_helper.h |  5 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5fecdc1..1f36016 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -541,6 +541,33 @@ int drm_dp_downstream_hw_rev(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
 
 /**
+ * drm_dp_downstream_sw_rev() - read DP branch device SW revision
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns SW revision on success or negative error code on failure
+ */
+int drm_dp_downstream_sw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+struct drm_dp_aux *aux, struct drm_dp_link *link)
+{
+   uint8_t tmp[2];
+   int err;
+
+   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+   return -EINVAL;
+
+   err = drm_dp_dpcd_read(aux, DP_BRANCH_SW_REV, tmp, 2);
+
+   if (err < 0)
+   return err;
+
+   link->ds_sw_rev.major = tmp[0];
+   link->ds_sw_rev.minor = tmp[1];
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_downstream_sw_rev);
+
+/**
  * drm_dp_downstream_id() - identify branch device
  * @aux: DisplayPort AUX channel
  *
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1127948..45366aa 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -447,6 +447,7 @@
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
 #define DP_BRANCH_HW_REV0x509
+#define DP_BRANCH_SW_REV0x50A
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -815,6 +816,7 @@ struct drm_dp_link {
unsigned int num_lanes;
unsigned long capabilities;
struct drm_dp_ds_revision ds_hw_rev;
+   struct drm_dp_ds_revision ds_sw_rev;
 };
 
 int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
@@ -829,6 +831,9 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char 
id[6]);
 int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
 struct drm_dp_aux *aux, struct drm_dp_link *link);
 
+int drm_dp_downstream_sw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+struct drm_dp_aux *aux, struct drm_dp_link *link);
+
 void drm_dp_aux_init(struct drm_dp_aux *aux);
 int drm_dp_aux_register(struct drm_dp_aux *aux);
 void drm_dp_aux_unregister(struct drm_dp_aux *aux);
-- 
1.9.1

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


[Intel-gfx] [PATCH v7 1/5] drm: Read DP branch device HW revision

2016-08-08 Thread Mika Kahola
HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.

v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c  | 27 +++
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 include/drm/drm_dp_helper.h  |  9 +
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 75b2873..5fecdc1 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -514,6 +514,33 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
 
 /**
+ * drm_dp_downstream_hw_rev() - read DP branch device HW revision
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on succes or negative error code on failure
+ */
+int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+struct drm_dp_aux *aux, struct drm_dp_link *link)
+{
+   uint8_t tmp;
+   int err;
+
+   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+   return -EINVAL;
+
+   err = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1);
+
+   if (err < 0)
+   return err;
+
+   link->ds_hw_rev.major = (tmp & 0xf0) >> 4;
+   link->ds_hw_rev.minor = tmp & 0xf;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
+
+/**
  * drm_dp_downstream_id() - identify branch device
  * @aux: DisplayPort AUX channel
  *
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e74d851..a6eccf5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -865,6 +865,7 @@ struct intel_dp {
uint8_t num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
struct drm_dp_aux aux;
+   struct drm_dp_link link;
uint8_t train_set[4];
int panel_power_up_delay;
int panel_power_down_delay;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8e1fe58..1127948 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -446,6 +446,7 @@
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
+#define DP_BRANCH_HW_REV0x509
 
 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -803,11 +804,17 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
  */
 #define DP_LINK_CAP_ENHANCED_FRAMING (1 << 0)
 
+struct drm_dp_ds_revision {
+   int major;
+   int minor;
+};
+
 struct drm_dp_link {
unsigned char revision;
unsigned int rate;
unsigned int num_lanes;
unsigned long capabilities;
+   struct drm_dp_ds_revision ds_hw_rev;
 };
 
 int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
@@ -819,6 +826,8 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
  const u8 port_cap[4]);
 int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);
+int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+struct drm_dp_aux *aux, struct drm_dp_link *link);
 
 void drm_dp_aux_init(struct drm_dp_aux *aux);
 int drm_dp_aux_register(struct drm_dp_aux *aux);
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

2016-08-08 Thread Ville Syrjälä
On Fri, Aug 05, 2016 at 03:45:19PM -0700, Clint Taylor wrote:
> On 08/03/2016 06:36 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Dell UP2414Q doesn't like it when we're driving it in MST mode, and then
> > reboot the machine. After reboot, the monitor is somehow confused and
> > refuses to do the payload allocation:
> >   [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 282 8
> >   [drm:drm_dp_dpcd_write_payload] status not set after read payload table 
> > status 0
> > and thus we're left with a black screen until the monitor power is
> > toggled.
> >
> > It seems that if we shut down things gracefully prior to rebooting, the
> > monitor doesn't get confused like this. So let's try to shut down all
> > the displays gracefully on reboot. The downside is that we will
> > introduce the reboot notifier to all the modesetl locks. So if there's
> > a locking bug around, we might not be able to reboot the machine
> > gracefully. sysrq reboot will still work though, as it will not
> > call the notifiers.
> >
> > While we do this, we can eliminate the eDP reboot notifier, which is
> > there to shut down the panel power and make sure the firmware won't
> > violate the panel power cycle delay post-reboot. Since we're now
> > shutting eDP down properly, we can mostly just rip out the eDP notifier.
> > We still need to do the panel power cycle wait though, as that would
> > normally get postponed until the next modeset. So let's move that part
> > into intel_panel so that other display types will get the same treatment
> > as a bonus.
> >
> > The Dell UP2414Q can often get even more confused, and sometimes what
> > you have to do is: switch to another input on the monitor, toggle the
> > monitor power, switch the input back to the original setting. And
> > sometimes it seems you just have to yank the power cable entirely. I'm
> > not sure if this reboot notifier might avoid some of these other
> > failure modes as well, but I'm pretty sure it can't hurt at least.
> >
> 
> While testing this change on SKL if 2 crtc's are enabled resume from 
> suspend is 500ms longer than a single crtc resume. Are we calling the 
> T12 msleep(500) for non eDP panels?

Seems unlikely, unless we misdetect DP as eDP. 500ms sure sounds a lot
for non-eDP though.

> 
> During testing VDD to the panel, the T12 panel timeout requirement is 
> being meet at >500ms during reboot and suspend/resume.
> 
> > Cc: Clint Taylor 
> > Cc: Paulo Zanoni 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h  |  2 ++
> >   drivers/gpu/drm/i915/intel_display.c | 24 ++
> >   drivers/gpu/drm/i915/intel_dp.c  | 49 
> > ++--
> >   drivers/gpu/drm/i915/intel_drv.h |  7 +++---
> >   drivers/gpu/drm/i915/intel_dsi.c |  3 ++-
> >   drivers/gpu/drm/i915/intel_dvo.c |  2 +-
> >   drivers/gpu/drm/i915/intel_lvds.c|  3 ++-
> >   drivers/gpu/drm/i915/intel_panel.c   | 29 -
> >   8 files changed, 65 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 65ada5d2f88c..f8eb8c7de007 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1727,6 +1727,8 @@ struct intel_wm_config {
> >   struct drm_i915_private {
> > struct drm_device drm;
> >
> > +   struct notifier_block reboot_notifier;
> > +
> > struct kmem_cache *objects;
> > struct kmem_cache *vmas;
> > struct kmem_cache *requests;
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a8e8cc8dfae9..2192a21aa6c9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -31,6 +31,8 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> > +#include 
> >   #include 
> >   #include 
> >   #include "intel_drv.h"
> > @@ -15578,6 +15580,23 @@ fail:
> > drm_modeset_acquire_fini();
> >   }
> >
> > +
> > +static int intel_reboot_notifier(struct notifier_block *nb,
> > +unsigned long code, void *unused)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   container_of(nb, typeof(*dev_priv), reboot_notifier);
> > +
> > +   if (code != SYS_RESTART)
> > +   return 0;
> > +
> > +   intel_display_suspend(_priv->drm);
> > +
> 
> Need to check to make sure there is a panel before calling 
> intel_panel_reboot_notifier().
> 
> > +   intel_panel_reboot_notifier(dev_priv);
> > +
> > +   return 0;
> > +}
> > +
> >   void intel_modeset_init(struct drm_device *dev)
> >   {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > @@ -15706,6 +15725,9 @@ void intel_modeset_init(struct drm_device *dev)
> >  * since the watermark calculation done here will use pstate->fb.
> > 

Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

2016-08-08 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 12:47:09PM +0100, Dave Gordon wrote:
> On 06/08/16 09:29, Chris Wilson wrote:
> > On Sat, Aug 06, 2016 at 10:09:16AM +0200, Lukas Wunner wrote:
> >> On Wed, Aug 03, 2016 at 04:36:18PM +0300, ville.syrj...@linux.intel.com 
> >> wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> Dell UP2414Q doesn't like it when we're driving it in MST mode, and then
> >>> reboot the machine. After reboot, the monitor is somehow confused and
> >>> refuses to do the payload allocation:
> >>>  [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 282 8
> >>>  [drm:drm_dp_dpcd_write_payload] status not set after read payload table 
> >>> status 0
> >>> and thus we're left with a black screen until the monitor power is
> >>> toggled.
> >>>
> >>> It seems that if we shut down things gracefully prior to rebooting, the
> >>> monitor doesn't get confused like this. So let's try to shut down all
> >>> the displays gracefully on reboot. The downside is that we will
> >>> introduce the reboot notifier to all the modesetl locks. So if there's
> >>> a locking bug around, we might not be able to reboot the machine
> >>> gracefully. sysrq reboot will still work though, as it will not
> >>> call the notifiers.
> >>
> >> struct pci_driver has a ->shutdown hook which is currently not defined
> >> in i915_pci_driver. How about using that instead of reboot_notifier
> >> to avoid potential locking issues?
> >
> > Interestingly that is also called prior to kexec. Doing a
> > i915_gem_suspend at that point I think would stop some of the GPU faults
> > we get across kexec.
> > -Chris
> 
> Agreed; we've had issues with things such as the GuC being left running 
> across kexec, which causes firmware load to fail cos it's write-once!
> Doing a clean suspend before kexec would certainly help here.

I also realized that even my display suspend is somewhat insufficient
as I didn't consider hpds, ->detect() etc. potentially turning on vdd
again. I thought I might have to start reworking the hpd disable to not
depend on intel_runtime_pm_disable_interrupts(), but if we're going to
want a full blown suspend anyway I might not bother.

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


Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

2016-08-08 Thread Dave Gordon

On 06/08/16 09:29, Chris Wilson wrote:

On Sat, Aug 06, 2016 at 10:09:16AM +0200, Lukas Wunner wrote:

On Wed, Aug 03, 2016 at 04:36:18PM +0300, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Dell UP2414Q doesn't like it when we're driving it in MST mode, and then
reboot the machine. After reboot, the monitor is somehow confused and
refuses to do the payload allocation:
 [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 282 8
 [drm:drm_dp_dpcd_write_payload] status not set after read payload table status 0
and thus we're left with a black screen until the monitor power is
toggled.

It seems that if we shut down things gracefully prior to rebooting, the
monitor doesn't get confused like this. So let's try to shut down all
the displays gracefully on reboot. The downside is that we will
introduce the reboot notifier to all the modesetl locks. So if there's
a locking bug around, we might not be able to reboot the machine
gracefully. sysrq reboot will still work though, as it will not
call the notifiers.


struct pci_driver has a ->shutdown hook which is currently not defined
in i915_pci_driver. How about using that instead of reboot_notifier
to avoid potential locking issues?


Interestingly that is also called prior to kexec. Doing a
i915_gem_suspend at that point I think would stop some of the GPU faults
we get across kexec.
-Chris


Agreed; we've had issues with things such as the GuC being left running 
across kexec, which causes firmware load to fail cos it's write-once!

Doing a clean suspend before kexec would certainly help here.

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


Re: [Intel-gfx] [PATCH 30/33] drm/i915: Record the RING_MODE register for post-mortem debugging

2016-08-08 Thread Joonas Lahtinen
On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> Just another useful register to inspect following a GPU hang.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   | 1 +
>  drivers/gpu/drm/i915/i915_gpu_error.c | 4 
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e7357656728e..b5abf88e908e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -534,6 +534,7 @@ struct drm_i915_error_state {
>   u32 tail;
>   u32 head;
>   u32 ctl;
> + u32 mode;
>   u32 hws;
>   u32 ipeir;
>   u32 ipehr;
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 5d8fd0beda2e..c48277fbe6a7 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -237,6 +237,8 @@ static void error_print_engine(struct 
> drm_i915_error_state_buf *m,
>   err_printf(m, "  HEAD:  0x%08x\n", ee->head);
>   err_printf(m, "  TAIL:  0x%08x\n", ee->tail);
>   err_printf(m, "  CTL:   0x%08x\n", ee->ctl);
> + err_printf(m, "  MODE:  0x%08x [idle? %d]\n",
> +    ee->mode, !!(ee->mode & MODE_IDLE));

yesno()?

>   err_printf(m, "  HWS:   0x%08x\n", ee->hws);
>   err_printf(m, "  ACTHD: 0x%08x %08x\n",
>      (u32)(ee->acthd>>32), (u32)ee->acthd);
> @@ -979,6 +981,8 @@ static void error_record_engine_registers(struct 
> drm_i915_error_state *error,
>   ee->head = I915_READ_HEAD(engine);
>   ee->tail = I915_READ_TAIL(engine);
>   ee->ctl = I915_READ_CTL(engine);
> + if (INTEL_GEN(dev_priv) > 2)
> + ee->mode = I915_READ_MODE(engine);

IS_GEN2 is used elsewhere in the code with I915_READ_MODE, either site
should be fixed.

Regards, Joonas

>  
>   if (I915_NEED_GFX_HWS(dev_priv)) {
>   i915_reg_t mmio;
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix wait_req unreferencing.

2016-08-08 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix wait_req unreferencing.
URL   : https://patchwork.freedesktop.org/series/10781/
State : failure

== Summary ==

Applying: drm/i915: Remove early return in prepare/cleanup plane
Applying: drm/i915: Drop reference to current state wait req as soon as it goes 
unused
fatal: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_display.c).
error: could not build fake ancestor
Patch failed at 0002 drm/i915: Drop reference to current state wait req as soon 
as it goes unused
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

___
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: Account for TSEG size when determining 865G stolen base

2016-08-08 Thread Patchwork
== Series Details ==

Series: drm/i915: Account for TSEG size when determining 865G stolen base
URL   : https://patchwork.freedesktop.org/series/10779/
State : failure

== Summary ==

Series 10779v1 drm/i915: Account for TSEG size when determining 865G stolen base
http://patchwork.freedesktop.org/api/1.0/series/10779/revisions/1/mbox

Test drv_module_reload_basic:
pass   -> SKIP   (fi-skl-i5-6260u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
pass   -> FAIL   (ro-ilk1-i5-650)

fi-hsw-i7-4770k  total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
fi-kbl-qkkr  total:107  pass:83   dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-i5-6260u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
fi-skl-i7-6700k  total:107  pass:84   dwarn:0   dfail:0   fail:0   skip:22 
fi-snb-i7-2600   total:107  pass:77   dwarn:0   dfail:0   fail:0   skip:29 
ro-bdw-i5-5250u  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5557U  total:107  pass:97   dwarn:0   dfail:0   fail:0   skip:9  
ro-bdw-i7-5600u  total:94   pass:69   dwarn:0   dfail:0   fail:0   skip:24 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:107  pass:87   dwarn:0   dfail:0   fail:0   skip:19 
ro-ilk1-i5-650   total:235  pass:172  dwarn:0   dfail:0   fail:3   skip:60 
ro-ivb-i7-3770   total:107  pass:80   dwarn:0   dfail:0   fail:0   skip:26 
ro-skl3-i5-6260u total:107  pass:98   dwarn:0   dfail:0   fail:0   skip:8  
ro-bdw-i7-5600u failed to connect after reboot
ro-hsw-i7-4770r failed to connect after reboot
ro-ivb2-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1761/

8ca71ca drm-intel-nightly: 2016y-08m-08d-09h-02m-24s UTC integration manifest
32bc6d7 drm/i915: Account for TSEG size when determining 865G stolen base

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


[Intel-gfx] [PATCH 1/2] drm/i915: Remove early return in prepare/cleanup plane

2016-08-08 Thread Maarten Lankhorst
This is a noop in prepare_plane, which already carefully handles this
with if guards and early return.

cleanup_plane_fb has it as a noop too, it only unpins old_fb and
unsets wait_req. The latter is a noop because prepare_plane won't
set wait_req when obj == NULL. It's also dangerous to keep because
plane->state may change before cleanup_plane_fb is called.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b12c8302580f..f56707289615 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14117,9 +14117,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
struct reservation_object *resv;
int ret = 0;
 
-   if (!obj && !old_obj)
-   return 0;
-
if (old_obj) {
struct drm_crtc_state *crtc_state =
drm_atomic_get_existing_crtc_state(new_state->state, 
plane->state->crtc);
@@ -14193,15 +14190,10 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
   const struct drm_plane_state *old_state)
 {
struct drm_device *dev = plane->dev;
-   struct intel_plane_state *old_intel_state;
struct intel_plane_state *intel_state = 
to_intel_plane_state(plane->state);
struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
-   struct drm_i915_gem_object *obj = intel_fb_obj(plane->state->fb);
-
-   old_intel_state = to_intel_plane_state(old_state);
-
-   if (!obj && !old_obj)
-   return;
+   struct intel_plane_state *old_intel_state =
+   to_intel_plane_state(old_state);
 
if (old_obj && (plane->type != DRM_PLANE_TYPE_CURSOR ||
!INTEL_INFO(dev)->cursor_needs_physical))
-- 
2.7.4

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


[Intel-gfx] [PATCH 0/2] drm/i915: Fix wait_req unreferencing.

2016-08-08 Thread Maarten Lankhorst
Small cleanup plus a fix for the reference dropping.
This removes a source of heisenbugs. :-)

Maarten Lankhorst (2):
  drm/i915: Remove early return in prepare/cleanup plane
  drm/i915: Drop reference to current state wait req as soon as it goes
unused

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

-- 
2.7.4

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


[Intel-gfx] [PATCH 2/2] drm/i915: Drop reference to current state wait req as soon as it goes unused

2016-08-08 Thread Maarten Lankhorst
There are two paths into intel_cleanup_plane_fb, the normal completion
path and the failure path.

In the failure case, intel_cleanup_plane_fb is called before
drm_atomic_helper_swap_state, so any wait_req reference made in
intel_prepare_plane_fb will be in old_intel_state->wait_req.

In the normal completion path, wait_req is not freed until
the next commit, which is no longer used after waiting.

Free it as soon as possible, so we don't hold on to it indefinitely.

Signed-off-by: Maarten Lankhorst 
Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Fixes: 849782575325 ("drm/i915: cleanup_plane_fb: also drop reference to 
current state wait_req")
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f56707289615..e72ad97998a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13754,6 +13754,8 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
/* EIO should be eaten, and we can't get interrupted in the
 * worker, and blocking commits have waited already. */
WARN_ON(ret);
+
+   i915_gem_request_assign(_plane_state->wait_req, NULL);
}
 
if (!state->legacy_cursor_update)
@@ -14190,7 +14192,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
   const struct drm_plane_state *old_state)
 {
struct drm_device *dev = plane->dev;
-   struct intel_plane_state *intel_state = 
to_intel_plane_state(plane->state);
struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
struct intel_plane_state *old_intel_state =
to_intel_plane_state(old_state);
@@ -14199,7 +14200,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
!INTEL_INFO(dev)->cursor_needs_physical))
intel_unpin_fb_obj(old_state->fb, old_state->rotation);
 
-   i915_gem_request_assign(_state->wait_req, NULL);
i915_gem_request_assign(_intel_state->wait_req, NULL);
 }
 
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

2016-08-08 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 11:08:33AM +0200, Maarten Lankhorst wrote:
> Op 08-08-16 om 10:57 schreef Ville Syrjälä:
> > On Mon, Aug 08, 2016 at 10:40:42AM +0200, Maarten Lankhorst wrote:
> >> Op 08-08-16 om 10:05 schreef Ville Syrjälä:
> >>> On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote:
>  Hey,
> 
>  Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com:
> > From: Maarten Lankhorst 
> >
> > This function would call drm_modeset_lock_all, while the suspend/resume
> > functions already have their own locking. Fix this by factoring out
> > __intel_display_resume, and calling the atomic helpers for duplicating
> > atomic state and disabling all crtc's during suspend.
> >
> > Changes since v1:
> > - Deal with -EDEADLK right after lock_all and clean up calls
> >   to hw readout.
> > - Always take all modeset locks so updates during gpu reset are blocked.
> > Changes since v2:
> > - Fix deadlock in intel_update_primary_planes.
> > - Move WARN_ON(EDEADLK) to __intel_display_resume.
> > - pctx -> ctx
> > - only call __intel_display_resume on success in intel_display_resume.
> > Changes since v3:
> > - Rebase on top of dev_priv -> dev change.
> > - Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
> > Changes since v4 [by vsyrjala]:
> > - Deal with skip_intermediate_wm
> > - Update comment w.r.t. mode_config.mutex vs. ->detect()
> > - Rebase due to INTEL_GEN() etc.
>  Setting skip_intermediate_wm seems to have already been upstreamed and I 
>  missed it, but
>  this may blow up in .crtc_enable, which programs in the intermediate 
>  wm's which is used
>  until all planes are enabled.
> >>> What blows up and how?
> >>>
> >>> Even if it can blow up we don't have any two stage wm stuff for pre-g4x at
> >>> this time anyway, so -ENOCARE at this point really.
> >>>
>  I fear this may blow up in interesting ways. And it should probably be 
>  using
>  dev_priv->wm.distrust_bios_wm instead like on SKL.
> >>> Sigh. How many ways do we need to do the same thing?
> >>>
> >>> Anywyas, what we should really do is sanitize the current wms better
> >>> at readout time, and then we shouldn't need these flags at all.
> >>>
> >> Yeah, slightly different approach of accomplishing the same. :-/
> >>
> >> distrust_bios_wm pulls in the whole state and recalculates it, while 
> >> sanitize_watermarks runs at the end of initial config.
> >> Maybe get_hw_state for ILK should set the flag too, and  then stuff final 
> >> wm in intermediate. And then kill off the skip_intermediate_wm flag.
> > Or just kill both flags and sanitize better.
> >
> The first flag is used by the watermark sanitization, second flag seems to be 
> useful to make the driver init faster, first commit (either by fbcon or 
> userspace) will incur the real penalty. This is similar to fastset, which is 
> also recalculated on the first modeset.

The skl flag looks to be about the DDB. Irrelevant on other platforms,
except gen2-4 if/when someone decides to implement DDB reallocation
for them.

-- 
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] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

2016-08-08 Thread David Weinehall
On Fri, Aug 05, 2016 at 11:24:12AM +0300, Jani Nikula wrote:
> On Thu, 04 Aug 2016, David Weinehall  wrote:
> > On Tue, Aug 02, 2016 at 04:09:49PM +0200, Daniel Vetter wrote:
> >> On Mon, Aug 01, 2016 at 11:18:15PM +0530, Kamble, Sagar A wrote:
> >> > Reviewed-by: Sagar Arun Kamble  >> > >
> >> 
> >> You're mailer wreaks havoc with your reviewed-by tags. Pleas fix this.
> >> 
> >> 
> >> > On 6/27/2016 8:10 PM, akash.g...@intel.com wrote:
> >> > > From: Akash Goel 
> >> > > 
> >> > > Updated the i915_drpc_info debugfs with coarse power gating & forcewake
> >> > > info for Gen9.
> >> > > 
> >> > > v2: Change all IS_GEN9() by gen >= 9 (Damien)
> >
> > For future reference, please use IS_GEN(dev_priv) >= 9 for expressions
> > such as this. My bad for not spotting this until the patch got merged.
> > Fret not, however, I've got a few patches that'll clean this up :)
> 
> David means INTEL_GEN(), not IS_GEN(). ;)

David indeed means INTEL_GEN(). Brainfart. :(


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


[Intel-gfx] [PATCH] drm/i915: Account for TSEG size when determining 865G stolen base

2016-08-08 Thread ville . syrjala
From: Ville Syrjälä 

Looks like the TSEG lives just above TOUD, stolen comes after TSEG.

The spec seems somewhat self-contradictory in places, in the ESMRAMC
register desctription it says:
 TSEG Size:
  10=(TOUD + 512 KB) to TOUD
  11 =(TOUD + 1 MB) to TOUD

so that agrees with TSEG being at TOUD. But the example given
elsehwere in the spec says:

 TOUD equals 62.5 MB = 03E7h
 TSEG selected as 512 KB in size,
 Graphics local memory selected as 1 MB in size
 General System RAM available in system = 62.5 MB
 General system RAM rangeh to 03E7h
 TSEG address range03F8h to 03FFh
 TSEG pre-allocated from03F8h to 03FFh
 Graphics local memory pre-allocated from03E8h to 03F7h

so here we have TSEG above stolen.

Real world evidence agrees with the TOUD->TSEG->stolen order however, so
let's fix up the code to account for the TSEG size.

Cc: Taketo Kabe 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
Fixes: 0ad98c74e093 ("drm/i915: Determine the stolen memory base address on 
gen2")
Fixes: a4dff76924fe ("x86/gpu: Add Intel graphics stolen memory quirk for gen2 
platforms")
Reported-by: Taketo Kabe 
Tested-by: Taketo Kabe 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473
Signed-off-by: Ville Syrjälä 
---
 arch/x86/kernel/early-quirks.c |  9 ++---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 23 +--
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index de7501edb21c..8b8852bc2f4a 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -317,16 +317,11 @@ static phys_addr_t __init i85x_stolen_base(int num, int 
slot, int func,
 static phys_addr_t __init i865_stolen_base(int num, int slot, int func,
   size_t stolen_size)
 {
-   u16 toud;
+   u16 toud = 0;
 
-   /*
-* FIXME is the graphics stolen memory region
-* always at TOUD? Ie. is it always the last
-* one to be allocated by the BIOS?
-*/
toud = read_pci_config_16(0, 0, 0, I865_TOUD);
 
-   return (phys_addr_t)toud << 16;
+   return (phys_addr_t)(toud << 16) + i845_tseg_size();
 }
 
 static phys_addr_t __init gen3_stolen_base(int num, int slot, int func,
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 310756c30723..62e1a439023e 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -115,17 +115,28 @@ static unsigned long i915_stolen_to_physical(struct 
drm_device *dev)
 
base = bsm & INTEL_BSM_MASK;
} else if (IS_I865G(dev)) {
+   u32 tseg_size = 0;
u16 toud = 0;
+   u8 tmp;
+
+   pci_bus_read_config_byte(dev->pdev->bus, PCI_DEVFN(0, 0),
+I845_ESMRAMC, );
+
+   if (tmp & TSEG_ENABLE) {
+   switch (tmp & I845_TSEG_SIZE_MASK) {
+   case I845_TSEG_SIZE_512K:
+   tseg_size = KB(512);
+   break;
+   case I845_TSEG_SIZE_1M:
+   tseg_size = MB(1);
+   break;
+   }
+   }
 
-   /*
-* FIXME is the graphics stolen memory region
-* always at TOUD? Ie. is it always the last
-* one to be allocated by the BIOS?
-*/
pci_bus_read_config_word(dev->pdev->bus, PCI_DEVFN(0, 0),
 I865_TOUD, );
 
-   base = toud << 16;
+   base = (toud << 16) + tseg_size;
} else if (IS_I85X(dev)) {
u32 tseg_size = 0;
u32 tom;
-- 
2.7.4

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance (rev4)

2016-08-08 Thread Patchwork
== Series Details ==

Series: series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's 
RCU dance (rev4)
URL   : https://patchwork.freedesktop.org/series/10770/
State : failure

== Summary ==

  CC  drivers/usb/storage/usb.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  CC  drivers/usb/storage/initializers.o
  CC  drivers/net/phy/mdio_device.o
  CC  drivers/net/phy/swphy.o
  CC [M]  drivers/net/usb/mcs7830.o
  CC [M]  drivers/net/usb/usbnet.o
  CC [M]  drivers/net/phy/lxt.o
  CC [M]  drivers/net/usb/cdc_ncm.o
  CC  drivers/usb/storage/sierra_ms.o
  CC [M]  drivers/net/phy/smsc.o
  CC  drivers/usb/storage/option_ms.o
  CC [M]  drivers/net/phy/bcm-phy-lib.o
  CC  drivers/usb/storage/usual-tables.o
  CC [M]  drivers/net/phy/broadcom.o
  CC [M]  drivers/net/phy/bcm7xxx.o
  CC [M]  drivers/net/phy/bcm87xx.o
  CC [M]  drivers/net/phy/realtek.o
  CC [M]  drivers/net/phy/fixed_phy.o
  LD  drivers/net/phy/libphy.o
  LD  drivers/net/phy/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/storage/built-in.o
  LD  drivers/usb/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:975: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/CI_Patchwork_build_2251

___
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: Move common seqno reset to intel_engine_cs.c

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 10:40:35AM +0100, Matthew Auld wrote:
> In which header does the prototype for intel_engine_init_seqno now exist?

Same as before, intel_ringbuffer.h. We haven't yet decided upon
splitting that between engine submission and actual ring operations yet.
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Store clipped coordinates in drm_plane_state (rev3)

2016-08-08 Thread Patchwork
== Series Details ==

Series: drm: Store clipped coordinates in drm_plane_state (rev3)
URL   : https://patchwork.freedesktop.org/series/10279/
State : failure

== Summary ==

  CC  drivers/gpio/gpiolib-acpi.o
  CC  drivers/input/mouse/alps.o
  CC  drivers/input/mouse/focaltech.o
  CC  drivers/input/mouse/byd.o
  CC  drivers/firmware/efi/libstub/gop.o
  CC  drivers/input/mouse/elantech.o
  CC  drivers/input/mouse/logips2pp.o
  CC  drivers/input/mouse/lifebook.o
  CC [M]  drivers/i2c/busses/i2c-designware-core.o
  CC  drivers/input/mouse/trackpoint.o
  CC [M]  drivers/i2c/busses/i2c-designware-platdrv.o
  CC  drivers/input/mouse/cypress_ps2.o
  CC [M]  drivers/i2c/busses/i2c-designware-pcidrv.o
  CC [M]  drivers/input/mouse/synaptics_usb.o
  LD  drivers/hid/usbhid/usbhid.o
  LD  drivers/hid/usbhid/built-in.o
  LD  drivers/hid/built-in.o
  AR  drivers/firmware/efi/libstub/lib.a
  LD  drivers/firmware/efi/built-in.o
  LD  drivers/firmware/built-in.o
  LD  drivers/gpio/built-in.o
  LD [M]  drivers/i2c/busses/i2c-designware-platform.o
  LD [M]  drivers/i2c/busses/i2c-designware-pci.o
  LD  drivers/i2c/built-in.o
  LD  drivers/input/mouse/psmouse.o
  LD  drivers/input/mouse/built-in.o
  LD  drivers/input/built-in.o
  LD  drivers/iommu/built-in.o
Makefile:975: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Full logs at /archive/deploy/logs/CI_Patchwork_build_2250

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


Re: [Intel-gfx] [PATCH 02/33] drm/i915: Do not overwrite the request with zero on reallocation

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 11:25:56AM +0200, Daniel Vetter wrote:
> On Sun, Aug 07, 2016 at 03:45:10PM +0100, Chris Wilson wrote:
> > When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915:
> > Enable lockless lookup of request tracking via RCU"), we acknowledge that
> > we may race with another thread that could have reallocated the request.
> > In order for the first thread not to blow up, the second thread must not
> > clear the request completed before overwriting it. In the RCU lookup, we
> > allow for the engine/seqno to be replaced but we do not allow for it to
> > be zeroed.
> > 
> > The choice we make is to either add extra checking to the RCU lookup, or
> > embrace the inherent races (as intended). It is more complicated as we
> > need to manually clear everything we depend upon being zero initialised,
> > but we benefit from not emiting the memset() to clear the entire
> > frequently allocated structure (that memset turns up in throughput
> > profiles). And at the same time, the lookup remains flexible for future
> > adjustments.
> > 
> > v2: Old style LRC requires another variable to be initialize. (The
> > danger inherent in not zeroing everything.)
> > v3: request->batch also needs to be cleared
> > 
> > Fixes: 0eafec6d3244 ("drm/i915: Enable lockless lookup of request...")
> > Signed-off-by: Chris Wilson 
> > Cc: "Goel, Akash" 
> > Cc: Daniel Vetter 
> > Cc: Joonas Lahtinen 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_request.c | 37 
> > -
> >  drivers/gpu/drm/i915/i915_gem_request.h | 11 ++
> >  2 files changed, 47 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > b/drivers/gpu/drm/i915/i915_gem_request.c
> > index 6a1661643d3d..b7ffde002a62 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > @@ -355,7 +355,35 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
> > if (req && i915_gem_request_completed(req))
> > i915_gem_request_retire(req);
> >  
> > -   req = kmem_cache_zalloc(dev_priv->requests, GFP_KERNEL);
> > +   /* Beware: Dragons be flying overhead.
> > +*
> > +* We use RCU to look up requests in flight. The lookups may
> > +* race with the request being allocated from the slab freelist.
> > +* That is the request we are writing to here, may be in the process
> > +* of being read by __i915_gem_active_get_request_rcu(). As such,
> > +* we have to be very careful when overwriting the contents. During
> > +* the RCU lookup, we change chase the request->engine pointer,
> > +* read the request->fence.seqno and increment the reference count.
> > +*
> > +* The reference count is incremented atomically. If it is zero,
> > +* the lookup knows the request is unallocated and complete. Otherwise,
> > +* it is either still in use, or has been reallocated and reset
> > +* with fence_init(). This increment is safe for release as we check
> > +* that the request we have a reference to and matches the active
> > +* request.
> > +*
> > +* Before we increment the refcount, we chase the request->engine
> > +* pointer. We must not call kmem_cache_zalloc() or else we set
> > +* that pointer to NULL and cause a crash during the lookup. If
> > +* we see the request is completed (based on the value of the
> > +* old engine and seqno), the lookup is complete and reports NULL.
> > +* If we decide the request is not completed (new engine or seqno),
> > +* then we grab a reference and double check that it is still the
> > +* active request - which it won't be and restart the lookup.
> > +*
> > +* Do not use kmem_cache_zalloc() here!
> > +*/
> > +   req = kmem_cache_alloc(dev_priv->requests, GFP_KERNEL);
> > if (!req)
> > return ERR_PTR(-ENOMEM);
> >  
> > @@ -375,6 +403,13 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
> > req->engine = engine;
> > req->ctx = i915_gem_context_get(ctx);
> 
> See my earlier review - if we go with this I think we should fully embrace
> it and not clear anything where it's not needed. Otherwise we have a funny
> mix of defensive clearing to NULL and needing to be careful.
>   
> > +   /* No zalloc, must clear what we need by hand */
> > +   req->signaling.wait.tsk = NULL;
> 
> This shouldn't be non-NULL once the refcount has dropped to 0. Maybe a
> WARN_ON instead?

This is just from older code where we had the if (wait.tsk != NULL)
skip.

> > +   req->previous_context = NULL;
> 
> We unconditionally set this in advance_context (together with a bunch of
> other ring state tracked in the request). Do we really need to reset this
> here?

Previous_context may be used unset (along a failure path), so requires
initialising.

> > +   req->file_priv = NULL;
> 
> This 

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance (rev4)

2016-08-08 Thread Patchwork
== Series Details ==

Series: series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's 
RCU dance (rev4)
URL   : https://patchwork.freedesktop.org/series/10770/
State : failure

== Summary ==

Applying: drm/i915: Add smp_rmb() to busy ioctl's RCU dance
Applying: drm/i915: Do not overwrite the request with zero on reallocation
Applying: drm/i915: Move missed interrupt detection from hangcheck to 
breadcrumbs
Applying: drm/i915: Use RCU to annotate and enforce protection for breadcrumb's 
bh
Applying: drm/i915: Reduce amount of duplicate buffer information captured on 
error
Applying: drm/i915: Stop the machine whilst capturing the GPU crash dump
Applying: drm/i915: Store the active context object on all engines upon error
Applying: drm/i915: Move setting of request->batch into its single callsite
Applying: drm/i915: Mark unmappable GGTT entries as PIN_HIGH
Applying: drm/i915: Remove inactive/active list from debugfs
Applying: drm/i915: Focus debugfs/i915_gem_pinned to show only display pins
Applying: drm/i915: Reduce i915_gem_objects to only show object information
Applying: drm/i915: Remove redundant WARN_ON from __i915_add_request()
Applying: drm/i915: Create a VMA for an object
Applying: drm/i915: Track pinned vma inside guc
Applying: drm/i915: Convert fence computations to use vma directly
Applying: drm/i915: Use VMA directly for checking tiling parameters
Applying: drm/i915: Use VMA as the primary object for context state
Applying: drm/i915: Only clflush the context object when binding
Applying: drm/i915: Use VMA for ringbuffer tracking
Applying: drm/i915: Move common seqno reset to intel_engine_cs.c
Applying: drm/i915/overlay: Use VMA as the primary tracker for images
Applying: drm/i915: Use VMA as the primary tracker for semaphore page
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_drv.h
M   drivers/gpu/drm/i915/i915_gpu_error.c
M   drivers/gpu/drm/i915/intel_ringbuffer.c
M   drivers/gpu/drm/i915/intel_ringbuffer.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_ringbuffer.h
Auto-merging drivers/gpu/drm/i915/intel_ringbuffer.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.c
Auto-merging drivers/gpu/drm/i915/i915_gpu_error.c
Auto-merging drivers/gpu/drm/i915/i915_drv.h
error: Failed to merge in the changes.
Patch failed at 0023 drm/i915: Use VMA as the primary tracker for semaphore page
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


Re: [Intel-gfx] [PATCH 01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 10:30:25AM +0100, Chris Wilson wrote:
> On Mon, Aug 08, 2016 at 11:12:59AM +0200, Daniel Vetter wrote:
> > On Sun, Aug 07, 2016 at 03:45:09PM +0100, Chris Wilson wrote:
> > > In the debate as to whether the second read of active->request is
> > > ordered after the dependent reads of the first read of active->request,
> > > just give in and throw a smp_rmb() in there so that ordering of loads is
> > > assured.
> > > 
> > > v2: Explain the manual smp_rmb()
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Daniel Vetter 
> > > Reviewed-by: Daniel Vetter 
> > 
> > r-b confirmed.
> 
> It's still fishy that we are implying an SMP effect where we need to
> mandate the local processor order (that being the order evaluation of
> request = *active; engine = *request; *active). The two *active are
> already ordered across SMP, so we are only concered about this cpu. :|

More second thoughts. rcu_assign_pointer(NULL) is not visible to
rcu_access_pointer on another CPU without the smp_rmb. I think I am
overestimating the barriers in place for RCU, and they are weaker than
what I imagined for good reason.
-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] include/drm/i915_drm.h:96: possible bad bitmask ?

2016-08-08 Thread Daniel Vetter
On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
> Hello there,
> 
> Recent versions of gcc say this:
> 
> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
> requires 37 bits to represent, but ‘int’ only has 32 bits
> [-Wshift-overflow=]
> 
> Source code is
> 
> #define   INTEL_BSM_MASK (0x << 20)
> 
> Maybe something like
> 
> #define   INTEL_BSM_MASK (0xUL<< 20)
> 
> might be better.

Yup. Care to bake this into a patch (with s-o-b and everything per
Documentation/SubmittingPatches) so I can apply it?
-Daniel

> 
> 
> Regards
> 
> David Binderman
> ___
> 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 3/3] drm/i915: Move common seqno reset to intel_engine_cs.c

2016-08-08 Thread Matthew Auld
In which header does the prototype for intel_engine_init_seqno now exist?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 04/33] drm/i915: Use RCU to annotate and enforce protection for breadcrumb's bh

2016-08-08 Thread Daniel Vetter
On Sun, Aug 07, 2016 at 03:45:12PM +0100, Chris Wilson wrote:
> The bottom-half we use for processing the breadcrumb interrupt is a
> task, which is an RCU protected struct. When accessing this struct, we
> need to be holding the RCU read lock to prevent it disappearing beneath
> us. We can use the RCU annotation to mark our irq_seqno_bh pointer as
> being under RCU guard and then use the RCU accessors to both provide
> correct ordering of access through the pointer.
> 
> Most notably, this fixes the access from hard irq context to use the RCU
> read lock, which both Daniel and Tvrtko complained about.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Tvrtko Ursulin 

I'll leave sparse-checking this to 0day and runtime lockdep checking to CI
;-)

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +-
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 22 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c  |  2 --
>  drivers/gpu/drm/i915/intel_ringbuffer.h  | 21 ++---
>  4 files changed, 24 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index feec00f769e1..3d546b5c2e4c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3848,7 +3848,7 @@ static inline bool __i915_request_irq_complete(struct 
> drm_i915_gem_request *req)
>* is woken.
>*/
>   if (engine->irq_seqno_barrier &&
> - READ_ONCE(engine->breadcrumbs.irq_seqno_bh) == current &&
> + rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
>   cmpxchg_relaxed(>breadcrumbs.irq_posted, 1, 0)) {
>   struct task_struct *tsk;
>  
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index 8ecb3b6538fc..7552bd039565 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -60,10 +60,8 @@ static void intel_breadcrumbs_fake_irq(unsigned long data)
>* every jiffie in order to kick the oldest waiter to do the
>* coherent seqno check.
>*/
> - rcu_read_lock();
>   if (intel_engine_wakeup(engine))
>   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
> - rcu_read_unlock();
>  }
>  
>  static void irq_enable(struct intel_engine_cs *engine)
> @@ -232,7 +230,7 @@ static bool __intel_engine_add_wait(struct 
> intel_engine_cs *engine,
>   }
>   rb_link_node(>node, parent, p);
>   rb_insert_color(>node, >waiters);
> - GEM_BUG_ON(!first && !b->irq_seqno_bh);
> + GEM_BUG_ON(!first && !rcu_access_pointer(b->irq_seqno_bh));

Nit: reading through rcu docs I think the suggested accessor here is
rcu_dereference_protected for write-side access. That one allows the
compiler full freedom for reordering. otoh it's a bit more noise-y and meh
about optional debug checks anyway. So with or without that change:

Reviewed-by: Daniel Vetter 

>  
>   if (completed) {
>   struct rb_node *next = rb_next(completed);
> @@ -242,7 +240,7 @@ static bool __intel_engine_add_wait(struct 
> intel_engine_cs *engine,
>   GEM_BUG_ON(first);
>   b->timeout = wait_timeout();
>   b->first_wait = to_wait(next);
> - smp_store_mb(b->irq_seqno_bh, b->first_wait->tsk);
> + rcu_assign_pointer(b->irq_seqno_bh, b->first_wait->tsk);
>   /* As there is a delay between reading the current
>* seqno, processing the completed tasks and selecting
>* the next waiter, we may have missed the interrupt
> @@ -269,7 +267,7 @@ static bool __intel_engine_add_wait(struct 
> intel_engine_cs *engine,
>   GEM_BUG_ON(rb_first(>waiters) != >node);
>   b->timeout = wait_timeout();
>   b->first_wait = wait;
> - smp_store_mb(b->irq_seqno_bh, wait->tsk);
> + rcu_assign_pointer(b->irq_seqno_bh, wait->tsk);
>   /* After assigning ourselves as the new bottom-half, we must
>* perform a cursory check to prevent a missed interrupt.
>* Either we miss the interrupt whilst programming the hardware,
> @@ -280,7 +278,7 @@ static bool __intel_engine_add_wait(struct 
> intel_engine_cs *engine,
>*/
>   __intel_breadcrumbs_enable_irq(b);
>   }
> - GEM_BUG_ON(!b->irq_seqno_bh);
> + GEM_BUG_ON(!rcu_access_pointer(b->irq_seqno_bh));
>   GEM_BUG_ON(!b->first_wait);
>   GEM_BUG_ON(rb_first(>waiters) != >first_wait->node);
>  
> @@ -335,7 +333,7 @@ void intel_engine_remove_wait(struct intel_engine_cs 
> *engine,
>   const int priority = wakeup_priority(b, wait->tsk);
>   struct rb_node *next;
>  
> - 

[Intel-gfx] include/drm/i915_drm.h:96: possible bad bitmask ?

2016-08-08 Thread David Binderman
Hello there,

Recent versions of gcc say this:

include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshift-overflow=]

Source code is

#define   INTEL_BSM_MASK (0x << 20)

Maybe something like

#define   INTEL_BSM_MASK (0xUL<< 20)

might be better.


Regards

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


Re: [Intel-gfx] [PATCH 01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 11:12:59AM +0200, Daniel Vetter wrote:
> On Sun, Aug 07, 2016 at 03:45:09PM +0100, Chris Wilson wrote:
> > In the debate as to whether the second read of active->request is
> > ordered after the dependent reads of the first read of active->request,
> > just give in and throw a smp_rmb() in there so that ordering of loads is
> > assured.
> > 
> > v2: Explain the manual smp_rmb()
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> > Reviewed-by: Daniel Vetter 
> 
> r-b confirmed.

It's still fishy that we are implying an SMP effect where we need to
mandate the local processor order (that being the order evaluation of
request = *active; engine = *request; *active). The two *active are
already ordered across SMP, so we are only concered about this cpu. :|
-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 02/33] drm/i915: Do not overwrite the request with zero on reallocation

2016-08-08 Thread Daniel Vetter
On Sun, Aug 07, 2016 at 03:45:10PM +0100, Chris Wilson wrote:
> When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915:
> Enable lockless lookup of request tracking via RCU"), we acknowledge that
> we may race with another thread that could have reallocated the request.
> In order for the first thread not to blow up, the second thread must not
> clear the request completed before overwriting it. In the RCU lookup, we
> allow for the engine/seqno to be replaced but we do not allow for it to
> be zeroed.
> 
> The choice we make is to either add extra checking to the RCU lookup, or
> embrace the inherent races (as intended). It is more complicated as we
> need to manually clear everything we depend upon being zero initialised,
> but we benefit from not emiting the memset() to clear the entire
> frequently allocated structure (that memset turns up in throughput
> profiles). And at the same time, the lookup remains flexible for future
> adjustments.
> 
> v2: Old style LRC requires another variable to be initialize. (The
> danger inherent in not zeroing everything.)
> v3: request->batch also needs to be cleared
> 
> Fixes: 0eafec6d3244 ("drm/i915: Enable lockless lookup of request...")
> Signed-off-by: Chris Wilson 
> Cc: "Goel, Akash" 
> Cc: Daniel Vetter 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 37 
> -
>  drivers/gpu/drm/i915/i915_gem_request.h | 11 ++
>  2 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 6a1661643d3d..b7ffde002a62 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -355,7 +355,35 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
>   if (req && i915_gem_request_completed(req))
>   i915_gem_request_retire(req);
>  
> - req = kmem_cache_zalloc(dev_priv->requests, GFP_KERNEL);
> + /* Beware: Dragons be flying overhead.
> +  *
> +  * We use RCU to look up requests in flight. The lookups may
> +  * race with the request being allocated from the slab freelist.
> +  * That is the request we are writing to here, may be in the process
> +  * of being read by __i915_gem_active_get_request_rcu(). As such,
> +  * we have to be very careful when overwriting the contents. During
> +  * the RCU lookup, we change chase the request->engine pointer,
> +  * read the request->fence.seqno and increment the reference count.
> +  *
> +  * The reference count is incremented atomically. If it is zero,
> +  * the lookup knows the request is unallocated and complete. Otherwise,
> +  * it is either still in use, or has been reallocated and reset
> +  * with fence_init(). This increment is safe for release as we check
> +  * that the request we have a reference to and matches the active
> +  * request.
> +  *
> +  * Before we increment the refcount, we chase the request->engine
> +  * pointer. We must not call kmem_cache_zalloc() or else we set
> +  * that pointer to NULL and cause a crash during the lookup. If
> +  * we see the request is completed (based on the value of the
> +  * old engine and seqno), the lookup is complete and reports NULL.
> +  * If we decide the request is not completed (new engine or seqno),
> +  * then we grab a reference and double check that it is still the
> +  * active request - which it won't be and restart the lookup.
> +  *
> +  * Do not use kmem_cache_zalloc() here!
> +  */
> + req = kmem_cache_alloc(dev_priv->requests, GFP_KERNEL);
>   if (!req)
>   return ERR_PTR(-ENOMEM);
>  
> @@ -375,6 +403,13 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
>   req->engine = engine;
>   req->ctx = i915_gem_context_get(ctx);

See my earlier review - if we go with this I think we should fully embrace
it and not clear anything where it's not needed. Otherwise we have a funny
mix of defensive clearing to NULL and needing to be careful.
  
> + /* No zalloc, must clear what we need by hand */
> + req->signaling.wait.tsk = NULL;

This shouldn't be non-NULL once the refcount has dropped to 0. Maybe a
WARN_ON instead?

> + req->previous_context = NULL;

We unconditionally set this in advance_context (together with a bunch of
other ring state tracked in the request). Do we really need to reset this
here?

> + req->file_priv = NULL;

This is already cleared in either request_retire or _release. Again maybe
just a WARN_ON?.

> + req->batch_obj = NULL;

Agreed with this one, we might reuse the request for a non-execbuf
request. But I think we also need to reset ->pid here.

> + req->elsp_submitted = 0;

Needed, but feels misplaced since it's lrc stuff. I think 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move common scratch allocation/destroy to intel_engine_cs.c

2016-08-08 Thread Matthew Auld
I take it that this patch belongs in the previous series where you
introduce the nullify helper?

Assuming that:
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 01/33] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

2016-08-08 Thread Daniel Vetter
On Sun, Aug 07, 2016 at 03:45:09PM +0100, Chris Wilson wrote:
> In the debate as to whether the second read of active->request is
> ordered after the dependent reads of the first read of active->request,
> just give in and throw a smp_rmb() in there so that ordering of loads is
> assured.
> 
> v2: Explain the manual smp_rmb()
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 

r-b confirmed.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem.c | 25 -
>  drivers/gpu/drm/i915/i915_gem_request.h |  3 +++
>  2 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f4f8eaa90f2a..654f0b015f97 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3735,7 +3735,7 @@ i915_gem_object_ggtt_unpin_view(struct 
> drm_i915_gem_object *obj,
>   i915_vma_unpin(i915_gem_obj_to_ggtt_view(obj, view));
>  }
>  
> -static __always_inline unsigned __busy_read_flag(unsigned int id)
> +static __always_inline unsigned int __busy_read_flag(unsigned int id)
>  {
>   /* Note that we could alias engines in the execbuf API, but
>* that would be very unwise as it prevents userspace from
> @@ -3753,7 +3753,7 @@ static __always_inline unsigned int 
> __busy_write_id(unsigned int id)
>   return id;
>  }
>  
> -static __always_inline unsigned
> +static __always_inline unsigned int
>  __busy_set_if_active(const struct i915_gem_active *active,
>unsigned int (*flag)(unsigned int id))
>  {
> @@ -3770,19 +3770,34 @@ __busy_set_if_active(const struct i915_gem_active 
> *active,
>  
>   id = request->engine->exec_id;
>  
> - /* Check that the pointer wasn't reassigned and overwritten. */
> + /* Check that the pointer wasn't reassigned and overwritten.
> +  *
> +  * In __i915_gem_active_get_rcu(), we enforce ordering between
> +  * the first rcu pointer dereference (imposing a
> +  * read-dependency only on access through the pointer) and
> +  * the second lockless access through the memory barrier
> +  * following a successful atomic_inc_not_zero(). Here there
> +  * is no such barrier, and so we must manually insert an
> +  * explicit read barrier to ensure that the following
> +  * access occurs after all the loads through the first
> +  * pointer.
> +  *
> +  * The corresponding write barrier is part of
> +  * rcu_assign_pointer().
> +  */
> + smp_rmb();
>   if (request == rcu_access_pointer(active->request))
>   return flag(id);
>   } while (1);
>  }
>  
> -static inline unsigned
> +static __always_inline unsigned int
>  busy_check_reader(const struct i915_gem_active *active)
>  {
>   return __busy_set_if_active(active, __busy_read_flag);
>  }
>  
> -static inline unsigned
> +static __always_inline unsigned int
>  busy_check_writer(const struct i915_gem_active *active)
>  {
>   return __busy_set_if_active(active, __busy_write_id);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
> b/drivers/gpu/drm/i915/i915_gem_request.h
> index 3496e28785e7..b2456dede3ad 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.h
> +++ b/drivers/gpu/drm/i915/i915_gem_request.h
> @@ -497,6 +497,9 @@ __i915_gem_active_get_rcu(const struct i915_gem_active 
> *active)
>* incremented) then the following read for rcu_access_pointer()
>* must occur after the atomic operation and so confirm
>* that this request is the one currently being tracked.
> +  *
> +  * The corresponding write barrier is part of
> +  * rcu_assign_pointer().
>*/
>   if (!request || request == rcu_access_pointer(active->request))
>   return rcu_pointer_handoff(request);
> -- 
> 2.8.1
> 

-- 
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 14/33] drm/i915: Create a VMA for an object

2016-08-08 Thread Chris Wilson
On Mon, Aug 08, 2016 at 12:01:07PM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > In many places, we wish to store the VMA in preference to the object
> > itself and so being able to create the persistent VMA is useful.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  2 ++
> >  drivers/gpu/drm/i915/i915_gem_gtt.c | 10 ++
> >  drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +
> >  3 files changed, 17 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 826486d03e8e..2d8f32cd726d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3903,4 +3903,6 @@ static inline bool __i915_request_irq_complete(struct 
> > drm_i915_gem_request *req)
> >     return false;
> >  }
> >  
> > +#define nullify(ptr) ({typeof(*ptr) T = *(ptr); *(ptr) = NULL; T;})
> > +
> 
> Random lost hunk here.

In the next patches where I use i915_vma_create() I also use this
helper. It was just conveience.

> >  #endif
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 18c7c9644761..ce53f08186fa 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -3388,6 +3388,16 @@ __i915_gem_vma_create(struct drm_i915_gem_object 
> > *obj,
> >  }
> >  
> >  struct i915_vma *
> > +i915_vma_create(struct drm_i915_gem_object *obj,
> > +   struct i915_address_space *vm,
> > +   const struct i915_ggtt_view *view)
> > +{
> > +   GEM_BUG_ON(view ? i915_gem_obj_to_ggtt_view(obj, view) : 
> > i915_gem_obj_to_vma(obj, vm));
> 
> GEM_BUG_ON(view && !i915_is_ggtt(vm)) ?

We have that as a WARN_ON inside create(), I suspose it doesn't hurt
here either and documents the interface.
-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 09/33] drm/i915: Mark unmappable GGTT entries as PIN_HIGH

2016-08-08 Thread Joonas Lahtinen
On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> We allocate a few objects into the GGTT that we never need to access via
> the mappable aperture (such as contexts, status pages). We can request
> that these are bound high in the VM to increase the amount of mappable
> aperture available. However, anything that may be frequently pinned
> (such as logical contexts) we want to use the fast search & insert.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/intel_lrc.c| 2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 309c5d9b1c57..c7f4b64b16f6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1182,7 +1182,7 @@ static int lrc_setup_wa_ctx_obj(struct intel_engine_cs 
> *engine, u32 size)
>   }
>  
>   ret = i915_gem_object_ggtt_pin(engine->wa_ctx.obj, NULL,
> -    0, PAGE_SIZE, 0);
> +    0, PAGE_SIZE, PIN_HIGH);
>   if (ret) {
>   DRM_DEBUG_DRIVER("pin LRC WA ctx backing obj failed: %d\n",
>    ret);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 16b726fe33eb..09f01c641c14 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2093,7 +2093,7 @@ static int intel_ring_context_pin(struct 
> i915_gem_context *ctx,
>  
>   if (ce->state) {
>   ret = i915_gem_object_ggtt_pin(ce->state, NULL, 0,
> -    ctx->ggtt_alignment, 0);
> +    ctx->ggtt_alignment, PIN_HIGH);
>   if (ret)
>   goto error;
>   }
> @@ -2629,7 +2629,8 @@ static void intel_ring_init_semaphores(struct 
> drm_i915_private *dev_priv,
>   i915.semaphores = 0;
>   } else {
>   i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);
> - ret = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
> + ret = i915_gem_object_ggtt_pin(obj, NULL,
> +    0, 0, PIN_HIGH);
>   if (ret != 0) {
>   i915_gem_object_put(obj);
>   DRM_ERROR("Failed to pin semaphore bo. 
> Disabling semaphores\n");
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

2016-08-08 Thread Maarten Lankhorst
Op 08-08-16 om 10:57 schreef Ville Syrjälä:
> On Mon, Aug 08, 2016 at 10:40:42AM +0200, Maarten Lankhorst wrote:
>> Op 08-08-16 om 10:05 schreef Ville Syrjälä:
>>> On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote:
 Hey,

 Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com:
> From: Maarten Lankhorst 
>
> This function would call drm_modeset_lock_all, while the suspend/resume
> functions already have their own locking. Fix this by factoring out
> __intel_display_resume, and calling the atomic helpers for duplicating
> atomic state and disabling all crtc's during suspend.
>
> Changes since v1:
> - Deal with -EDEADLK right after lock_all and clean up calls
>   to hw readout.
> - Always take all modeset locks so updates during gpu reset are blocked.
> Changes since v2:
> - Fix deadlock in intel_update_primary_planes.
> - Move WARN_ON(EDEADLK) to __intel_display_resume.
> - pctx -> ctx
> - only call __intel_display_resume on success in intel_display_resume.
> Changes since v3:
> - Rebase on top of dev_priv -> dev change.
> - Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
> Changes since v4 [by vsyrjala]:
> - Deal with skip_intermediate_wm
> - Update comment w.r.t. mode_config.mutex vs. ->detect()
> - Rebase due to INTEL_GEN() etc.
 Setting skip_intermediate_wm seems to have already been upstreamed and I 
 missed it, but
 this may blow up in .crtc_enable, which programs in the intermediate wm's 
 which is used
 until all planes are enabled.
>>> What blows up and how?
>>>
>>> Even if it can blow up we don't have any two stage wm stuff for pre-g4x at
>>> this time anyway, so -ENOCARE at this point really.
>>>
 I fear this may blow up in interesting ways. And it should probably be 
 using
 dev_priv->wm.distrust_bios_wm instead like on SKL.
>>> Sigh. How many ways do we need to do the same thing?
>>>
>>> Anywyas, what we should really do is sanitize the current wms better
>>> at readout time, and then we shouldn't need these flags at all.
>>>
>> Yeah, slightly different approach of accomplishing the same. :-/
>>
>> distrust_bios_wm pulls in the whole state and recalculates it, while 
>> sanitize_watermarks runs at the end of initial config.
>> Maybe get_hw_state for ILK should set the flag too, and  then stuff final wm 
>> in intermediate. And then kill off the skip_intermediate_wm flag.
> Or just kill both flags and sanitize better.
>
The first flag is used by the watermark sanitization, second flag seems to be 
useful to make the driver init faster, first commit (either by fbcon or 
userspace) will incur the real penalty. This is similar to fastset, which is 
also recalculated on the first modeset.

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


Re: [Intel-gfx] [PATCH 13/33] drm/i915: Remove redundant WARN_ON from __i915_add_request()

2016-08-08 Thread Joonas Lahtinen
On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> It's an outright programming error, so explode if it is ever hit.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index c6f523e2879c..0092f5e90cb2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -463,18 +463,12 @@ static void i915_gem_mark_busy(const struct 
> intel_engine_cs *engine)
>   */
>  void __i915_add_request(struct drm_i915_gem_request *request, bool 
> flush_caches)
>  {
> - struct intel_engine_cs *engine;
> - struct intel_ring *ring;
> + struct intel_engine_cs *engine = request->engine;
> + struct intel_ring *ring = request->ring;
>   u32 request_start;
>   u32 reserved_tail;
>   int ret;
>  
> - if (WARN_ON(!request))
> - return;
> -
> - engine = request->engine;
> - ring = request->ring;
> -
>   /*
>    * To ensure that this call will not fail, space for its emissions
>    * should already have been reserved in the ring buffer. Let the ring
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 14/33] drm/i915: Create a VMA for an object

2016-08-08 Thread Joonas Lahtinen
On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> In many places, we wish to store the VMA in preference to the object
> itself and so being able to create the persistent VMA is useful.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 10 ++
>  drivers/gpu/drm/i915/i915_gem_gtt.h |  5 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 826486d03e8e..2d8f32cd726d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3903,4 +3903,6 @@ static inline bool __i915_request_irq_complete(struct 
> drm_i915_gem_request *req)
>   return false;
>  }
>  
> +#define nullify(ptr) ({typeof(*ptr) T = *(ptr); *(ptr) = NULL; T;})
> +

Random lost hunk here.

>  #endif
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 18c7c9644761..ce53f08186fa 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3388,6 +3388,16 @@ __i915_gem_vma_create(struct drm_i915_gem_object *obj,
>  }
>  
>  struct i915_vma *
> +i915_vma_create(struct drm_i915_gem_object *obj,
> + struct i915_address_space *vm,
> + const struct i915_ggtt_view *view)
> +{
> + GEM_BUG_ON(view ? i915_gem_obj_to_ggtt_view(obj, view) : 
> i915_gem_obj_to_vma(obj, vm));

GEM_BUG_ON(view && !i915_is_ggtt(vm)) ?

> +
> + return __i915_gem_vma_create(obj, vm, view ?: _ggtt_view_normal);
> +}
> +
> +struct i915_vma *
>  i915_gem_obj_lookup_or_create_vma(struct drm_i915_gem_object *obj,
>     struct i915_address_space *vm)
>  {
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index cc56206a1600..ac47663a4d32 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -232,6 +232,11 @@ struct i915_vma {
>   struct drm_i915_gem_exec_object2 *exec_entry;
>  };
>  
> +struct i915_vma *
> +i915_vma_create(struct drm_i915_gem_object *obj,
> + struct i915_address_space *vm,
> + const struct i915_ggtt_view *view);
> +
>  static inline bool i915_vma_is_ggtt(const struct i915_vma *vma)
>  {
>   return vma->flags & I915_VMA_GGTT;
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

2016-08-08 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 10:40:42AM +0200, Maarten Lankhorst wrote:
> Op 08-08-16 om 10:05 schreef Ville Syrjälä:
> > On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote:
> >> Hey,
> >>
> >> Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com:
> >>> From: Maarten Lankhorst 
> >>>
> >>> This function would call drm_modeset_lock_all, while the suspend/resume
> >>> functions already have their own locking. Fix this by factoring out
> >>> __intel_display_resume, and calling the atomic helpers for duplicating
> >>> atomic state and disabling all crtc's during suspend.
> >>>
> >>> Changes since v1:
> >>> - Deal with -EDEADLK right after lock_all and clean up calls
> >>>   to hw readout.
> >>> - Always take all modeset locks so updates during gpu reset are blocked.
> >>> Changes since v2:
> >>> - Fix deadlock in intel_update_primary_planes.
> >>> - Move WARN_ON(EDEADLK) to __intel_display_resume.
> >>> - pctx -> ctx
> >>> - only call __intel_display_resume on success in intel_display_resume.
> >>> Changes since v3:
> >>> - Rebase on top of dev_priv -> dev change.
> >>> - Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
> >>> Changes since v4 [by vsyrjala]:
> >>> - Deal with skip_intermediate_wm
> >>> - Update comment w.r.t. mode_config.mutex vs. ->detect()
> >>> - Rebase due to INTEL_GEN() etc.
> >> Setting skip_intermediate_wm seems to have already been upstreamed and I 
> >> missed it, but
> >> this may blow up in .crtc_enable, which programs in the intermediate wm's 
> >> which is used
> >> until all planes are enabled.
> > What blows up and how?
> >
> > Even if it can blow up we don't have any two stage wm stuff for pre-g4x at
> > this time anyway, so -ENOCARE at this point really.
> >
> >> I fear this may blow up in interesting ways. And it should probably be 
> >> using
> >> dev_priv->wm.distrust_bios_wm instead like on SKL.
> > Sigh. How many ways do we need to do the same thing?
> >
> > Anywyas, what we should really do is sanitize the current wms better
> > at readout time, and then we shouldn't need these flags at all.
> >
> Yeah, slightly different approach of accomplishing the same. :-/
> 
> distrust_bios_wm pulls in the whole state and recalculates it, while 
> sanitize_watermarks runs at the end of initial config.
> Maybe get_hw_state for ILK should set the flag too, and  then stuff final wm 
> in intermediate. And then kill off the skip_intermediate_wm flag.

Or just kill both flags and sanitize better.

-- 
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 v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

2016-08-08 Thread Maarten Lankhorst
Op 08-08-16 om 10:05 schreef Ville Syrjälä:
> On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com:
>>> From: Maarten Lankhorst 
>>>
>>> This function would call drm_modeset_lock_all, while the suspend/resume
>>> functions already have their own locking. Fix this by factoring out
>>> __intel_display_resume, and calling the atomic helpers for duplicating
>>> atomic state and disabling all crtc's during suspend.
>>>
>>> Changes since v1:
>>> - Deal with -EDEADLK right after lock_all and clean up calls
>>>   to hw readout.
>>> - Always take all modeset locks so updates during gpu reset are blocked.
>>> Changes since v2:
>>> - Fix deadlock in intel_update_primary_planes.
>>> - Move WARN_ON(EDEADLK) to __intel_display_resume.
>>> - pctx -> ctx
>>> - only call __intel_display_resume on success in intel_display_resume.
>>> Changes since v3:
>>> - Rebase on top of dev_priv -> dev change.
>>> - Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
>>> Changes since v4 [by vsyrjala]:
>>> - Deal with skip_intermediate_wm
>>> - Update comment w.r.t. mode_config.mutex vs. ->detect()
>>> - Rebase due to INTEL_GEN() etc.
>> Setting skip_intermediate_wm seems to have already been upstreamed and I 
>> missed it, but
>> this may blow up in .crtc_enable, which programs in the intermediate wm's 
>> which is used
>> until all planes are enabled.
> What blows up and how?
>
> Even if it can blow up we don't have any two stage wm stuff for pre-g4x at
> this time anyway, so -ENOCARE at this point really.
>
>> I fear this may blow up in interesting ways. And it should probably be using
>> dev_priv->wm.distrust_bios_wm instead like on SKL.
> Sigh. How many ways do we need to do the same thing?
>
> Anywyas, what we should really do is sanitize the current wms better
> at readout time, and then we shouldn't need these flags at all.
>
Yeah, slightly different approach of accomplishing the same. :-/

distrust_bios_wm pulls in the whole state and recalculates it, while 
sanitize_watermarks runs at the end of initial config.
Maybe get_hw_state for ILK should set the flag too, and  then stuff final wm in 
intermediate. And then kill off the skip_intermediate_wm flag.

~Maarten

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


Re: [Intel-gfx] [PATCH 3/6] drm/i915: Check PSR setup time vs. vblank length

2016-08-08 Thread Jani Nikula
On Sat, 06 Aug 2016, Rodrigo Vivi  wrote:
> This patch is blocking PSR on panels that we know that our hardware support.

And it also fixes a regression on Linus' laptop, and it's been merged
upstream...

BR,
Jani.

>
> I wonder if:
> 1. This restrictions was for older platforms and spec is out dated
> 2. Or Spec is not documenting the restriction properly
> 3. Or we have some issue with out setup time calculation.
>
>
> On Tue, May 31, 2016 at 8:50 AM,   wrote:
>> From: Ville Syrjälä 
>>
>> Bspec says:
>> "Restriction : SRD must not be enabled when the PSR Setup time from DPCD
>> 00071h is greater than the time for vertical blank minus one line."
>>
>> Let's check for that and disallow PSR if we exceed the limit.
>>
>> Cc: Daniel Vetter 
>> Reviewed-by: Daniel Vetter 
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
>>  drivers/gpu/drm/i915/intel_psr.c| 19 ++-
>>  drivers/gpu/drm/i915/intel_sprite.c |  6 +++---
>>  3 files changed, 23 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 9b5f6634c558..56ae3b78e25e 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1672,6 +1672,8 @@ bool intel_sdvo_init(struct drm_device *dev,
>>
>>
>>  /* intel_sprite.c */
>> +int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>> +int usecs);
>>  int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
>>  int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
>>   struct drm_file *file_priv);
>> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
>> b/drivers/gpu/drm/i915/intel_psr.c
>> index 29a09bf6bd18..aacd8d1767f2 100644
>> --- a/drivers/gpu/drm/i915/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>> @@ -327,6 +327,9 @@ static bool intel_psr_match_conditions(struct intel_dp 
>> *intel_dp)
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct drm_crtc *crtc = dig_port->base.base.crtc;
>> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> +   const struct drm_display_mode *adjusted_mode =
>> +   _crtc->config->base.adjusted_mode;
>> +   int psr_setup_time;
>>
>> lockdep_assert_held(_priv->psr.lock);
>> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>> @@ -365,11 +368,25 @@ static bool intel_psr_match_conditions(struct intel_dp 
>> *intel_dp)
>> }
>>
>> if (IS_HASWELL(dev) &&
>> -   intel_crtc->config->base.adjusted_mode.flags & 
>> DRM_MODE_FLAG_INTERLACE) {
>> +   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
>> DRM_DEBUG_KMS("PSR condition failed: Interlaced is 
>> Enabled\n");
>> return false;
>> }
>>
>> +   psr_setup_time = drm_dp_psr_setup_time(intel_dp->psr_dpcd);
>> +   if (psr_setup_time < 0) {
>> +   DRM_DEBUG_KMS("PSR condition failed: Invalid PSR setup time 
>> (0x%02x)\n",
>> + intel_dp->psr_dpcd[1]);
>> +   return false;
>> +   }
>> +
>> +   if (intel_usecs_to_scanlines(adjusted_mode, psr_setup_time) >
>> +   adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vdisplay - 1) {
>> +   DRM_DEBUG_KMS("PSR condition failed: PSR setup time (%d us) 
>> too long\n",
>> + psr_setup_time);
>> +   return false;
>> +   }
>> +
>> dev_priv->psr.source_ok = true;
>> return true;
>>  }
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index 324ccb06397d..293b48007006 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -53,8 +53,8 @@ format_is_yuv(uint32_t format)
>> }
>>  }
>>
>> -static int usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>> - int usecs)
>> +int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>> +int usecs)
>>  {
>> /* paranoia */
>> if (!adjusted_mode->crtc_htotal)
>> @@ -91,7 +91,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>> vblank_start = DIV_ROUND_UP(vblank_start, 2);
>>
>> /* FIXME needs to be calibrated sensibly */
>> -   min = vblank_start - usecs_to_scanlines(adjusted_mode, 100);
>> +   min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, 100);
>> max = vblank_start - 1;
>>
>> local_irq_disable();
>> --
>> 2.7.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> 

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: Store clipped coordinates in drm_plane_state (rev3)

2016-08-08 Thread Patchwork
== Series Details ==

Series: drm: Store clipped coordinates in drm_plane_state (rev3)
URL   : https://patchwork.freedesktop.org/series/10279/
State : failure

== Summary ==

Applying: drm: Warn about negative sizes when calculating scale factor
Applying: drm: Store clipped src/dst coordinatee in drm_plane_state
Using index info to reconstruct a base tree...
M   include/drm/drm_crtc.h
Falling back to patching base and 3-way merge...
Auto-merging include/drm/drm_crtc.h
CONFLICT (content): Merge conflict in include/drm/drm_crtc.h
error: Failed to merge in the changes.
Patch failed at 0002 drm: Store clipped src/dst coordinatee in drm_plane_state
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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


Re: [Intel-gfx] [PATCH 6/6] drm/i915: Sanitize drm crtc vblank counter after DC reset frame count.

2016-08-08 Thread Daniel Vetter
On Fri, Aug 05, 2016 at 02:49:44PM -0700, Rodrigo Vivi wrote:
> On Thu, Aug 4, 2016 at 1:26 AM, Daniel Vetter  wrote:
> > On Wed, Aug 03, 2016 at 02:33:39PM -0700, Rodrigo Vivi wrote:
> >> DC state reset the frame counter that is a read-only register.
> >>
> >> So, besides blocking DC state on vblank let's restore the
> >> drm crtc vblank counter to a place we know it is reliable.
> >>
> >> Signed-off-by: Rodrigo Vivi 
> >> ---
> >>  drivers/gpu/drm/i915/i915_irq.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 4efe20c..82d6896 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -2759,7 +2759,9 @@ static int gen8_enable_vblank(struct drm_device 
> >> *dev, unsigned int pipe)
> >>  static void gen9_prepare_vblank(struct drm_device *dev, unsigned int pipe)
> >>  {
> >>   struct drm_i915_private *dev_priv = to_i915(dev);
> >> + struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> >>   intel_display_power_get(dev_priv, POWER_DOMAIN_VBLANK);
> >> + drm_crtc_vblank_sanitize_counter(crtc);
> >
> > I think this should be done within the platform power code. Otherwise
> > something else might keep the system out of dc states, but then we might
> > wreak havoc by calling this function here.
> 
> This is safe here because DC is handled as a power_well... so as long
> as there is one domain holding its reference DC will be off.
> 
> Also this needs to be in a place we are sure that vblanks are yet disabled.
> 
> Now it comes back to that point on how to make sure that we only run 1
> prepare pre-enable...
> 
> multiple prepare/unprepares will keep trying to resync it useless and
> if we have that WARN_ON we will get flooded

Yeah, my comment was under the assumption that there can be multiple
prepare/unprepare, and then it makes sense to reuse the refcounting we
already have. Still not sure it'll make sense to implement
prepare/unprepare refcounting in the vblank code, it'll be fairly tricky
in there. And for use useless, since our power well code already has
refcounting.
-Daniel
> 
> > -Daniel
> >
> >>  }
> >>
> >>  static void gen9_unprepare_vblank(struct drm_device *dev, unsigned int 
> >> pipe)
> >> --
> >> 2.4.3
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-de...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br

-- 
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 v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

2016-08-08 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 09:52:49AM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com:
> > From: Maarten Lankhorst 
> >
> > This function would call drm_modeset_lock_all, while the suspend/resume
> > functions already have their own locking. Fix this by factoring out
> > __intel_display_resume, and calling the atomic helpers for duplicating
> > atomic state and disabling all crtc's during suspend.
> >
> > Changes since v1:
> > - Deal with -EDEADLK right after lock_all and clean up calls
> >   to hw readout.
> > - Always take all modeset locks so updates during gpu reset are blocked.
> > Changes since v2:
> > - Fix deadlock in intel_update_primary_planes.
> > - Move WARN_ON(EDEADLK) to __intel_display_resume.
> > - pctx -> ctx
> > - only call __intel_display_resume on success in intel_display_resume.
> > Changes since v3:
> > - Rebase on top of dev_priv -> dev change.
> > - Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
> > Changes since v4 [by vsyrjala]:
> > - Deal with skip_intermediate_wm
> > - Update comment w.r.t. mode_config.mutex vs. ->detect()
> > - Rebase due to INTEL_GEN() etc.
> 
> Setting skip_intermediate_wm seems to have already been upstreamed and I 
> missed it, but
> this may blow up in .crtc_enable, which programs in the intermediate wm's 
> which is used
> until all planes are enabled.

What blows up and how?

Even if it can blow up we don't have any two stage wm stuff for pre-g4x at
this time anyway, so -ENOCARE at this point really.

> 
> I fear this may blow up in interesting ways. And it should probably be using
> dev_priv->wm.distrust_bios_wm instead like on SKL.

Sigh. How many ways do we need to do the same thing?

Anywyas, what we should really do is sanitize the current wms better
at readout time, and then we shouldn't need these flags at all.

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


[Intel-gfx] [PATCH 2/3] drm/i915: Move common scratch allocation/destroy to intel_engine_cs.c

2016-08-08 Thread Chris Wilson
Since the scratch allocation and cleanup is shared by all engine
submission backends, move it out of the legacy intel_ringbuffer.c and
into the new home for common routines, intel_engine_cs.c

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 50 +
 drivers/gpu/drm/i915/intel_lrc.c|  1 -
 drivers/gpu/drm/i915/intel_ringbuffer.c | 50 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 +--
 4 files changed, 51 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0dd3d1de18aa..1dec35441ab5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -195,6 +195,54 @@ void intel_engine_setup_common(struct intel_engine_cs 
*engine)
i915_gem_batch_pool_init(engine, >batch_pool);
 }
 
+int intel_engine_create_scratch(struct intel_engine_cs *engine, int size)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int ret;
+
+   WARN_ON(engine->scratch);
+
+   obj = i915_gem_object_create_stolen(>i915->drm, size);
+   if (!obj)
+   obj = i915_gem_object_create(>i915->drm, size);
+   if (IS_ERR(obj)) {
+   DRM_ERROR("Failed to allocate scratch page\n");
+   return PTR_ERR(obj);
+   }
+
+   vma = i915_vma_create(obj, >i915->ggtt.base, NULL);
+   if (IS_ERR(vma)) {
+   ret = PTR_ERR(vma);
+   goto err_unref;
+   }
+
+   ret = i915_vma_pin(vma, 0, 4096, PIN_GLOBAL | PIN_HIGH);
+   if (ret)
+   goto err_unref;
+
+   engine->scratch = vma;
+   DRM_DEBUG_DRIVER("%s pipe control offset: 0x%08llx\n",
+engine->name, vma->node.start);
+   return 0;
+
+err_unref:
+   i915_gem_object_put(obj);
+   return ret;
+}
+
+static void intel_engine_cleanup_scratch(struct intel_engine_cs *engine)
+{
+   struct i915_vma *vma;
+
+   vma = nullify(>scratch);
+   if (!vma)
+   return;
+
+   i915_vma_unpin(vma);
+   i915_gem_object_put(vma->obj);
+}
+
 /**
  * intel_engines_init_common - initialize cengine state which might require hw 
access
  * @engine: Engine to initialize.
@@ -226,6 +274,8 @@ int intel_engine_init_common(struct intel_engine_cs *engine)
  */
 void intel_engine_cleanup_common(struct intel_engine_cs *engine)
 {
+   intel_engine_cleanup_scratch(engine);
+
intel_engine_cleanup_cmd_parser(engine);
intel_engine_fini_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4dc77747911d..096eb8c2da17 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1844,7 +1844,6 @@ int logical_render_ring_init(struct intel_engine_cs 
*engine)
else
engine->init_hw = gen8_init_render_ring;
engine->init_context = gen8_init_rcs_context;
-   engine->cleanup = intel_engine_cleanup_scratch;
engine->emit_flush = gen8_emit_flush_render;
engine->emit_request = gen8_emit_request_render;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index f684fef895c1..af2d81ae3e7d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -613,54 +613,6 @@ out:
return ret;
 }
 
-void intel_engine_cleanup_scratch(struct intel_engine_cs *engine)
-{
-   struct i915_vma *vma;
-
-   vma = nullify(>scratch);
-   if (!vma)
-   return;
-
-   i915_vma_unpin(vma);
-   i915_gem_object_put(vma->obj);
-}
-
-int intel_engine_create_scratch(struct intel_engine_cs *engine, int size)
-{
-   struct drm_i915_gem_object *obj;
-   struct i915_vma *vma;
-   int ret;
-
-   WARN_ON(engine->scratch);
-
-   obj = i915_gem_object_create_stolen(>i915->drm, size);
-   if (!obj)
-   obj = i915_gem_object_create(>i915->drm, size);
-   if (IS_ERR(obj)) {
-   DRM_ERROR("Failed to allocate scratch page\n");
-   return PTR_ERR(obj);
-   }
-
-   vma = i915_vma_create(obj, >i915->ggtt.base, NULL);
-   if (IS_ERR(vma)) {
-   ret = PTR_ERR(vma);
-   goto err_unref;
-   }
-
-   ret = i915_vma_pin(vma, 0, 4096, PIN_GLOBAL | PIN_HIGH);
-   if (ret)
-   goto err_unref;
-
-   engine->scratch = vma;
-   DRM_DEBUG_DRIVER("%s pipe control offset: 0x%08llx\n",
-engine->name, vma->node.start);
-   return 0;
-
-err_unref:
-   i915_gem_object_put(obj);
-   return ret;
-}
-
 static int intel_ring_workarounds_emit(struct drm_i915_gem_request *req)
 {
struct intel_ring *ring = req->ring;
@@ -1311,8 +1263,6 @@ static void render_ring_cleanup(struct intel_engine_cs 

[Intel-gfx] [PATCH 1/3] drm/i915: Use VMA for scratch page tracking

2016-08-08 Thread Chris Wilson
Signed-off-by: Chris Wilson 
---

Accidental squashing during rebase.
-Chris

---
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c   |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 18 +--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 55 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 10 ++
 6 files changed, 46 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5d42fee75464..15eed897b498 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -660,7 +660,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
MI_STORE_REGISTER_MEM |
MI_SRM_LRM_GLOBAL_GTT);
intel_ring_emit_reg(ring, last_reg);
-   intel_ring_emit(ring, engine->scratch.gtt_offset);
+   intel_ring_emit(ring, engine->scratch->node.start);
intel_ring_emit(ring, MI_NOOP);
}
intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_ENABLE);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 09c3ae0c282a..2d93af0bb793 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1075,7 +1075,7 @@ static void i915_gem_record_rings(struct drm_i915_private 
*dev_priv,
if (HAS_BROKEN_CS_TLB(dev_priv))
ee->wa_batchbuffer =
i915_error_ggtt_object_create(dev_priv,
- 
engine->scratch.obj);
+ 
engine->scratch->obj);
 
if (request->ctx->engine[i].state) {
ee->ctx = 
i915_error_ggtt_object_create(dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9cbf5431c1e3..3deee0306e82 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11325,7 +11325,7 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
intel_ring_emit(ring, MI_STORE_REGISTER_MEM |
  MI_SRM_LRM_GLOBAL_GTT);
intel_ring_emit_reg(ring, DERRMR);
-   intel_ring_emit(ring, req->engine->scratch.gtt_offset + 256);
+   intel_ring_emit(ring, req->engine->scratch->node.start + 256);
if (IS_GEN8(dev)) {
intel_ring_emit(ring, 0);
intel_ring_emit(ring, MI_NOOP);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 198d59b272b2..4dc77747911d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -914,7 +914,7 @@ static inline int gen8_emit_flush_coherentl3_wa(struct 
intel_engine_cs *engine,
wa_ctx_emit(batch, index, (MI_STORE_REGISTER_MEM_GEN8 |
   MI_SRM_LRM_GLOBAL_GTT));
wa_ctx_emit_reg(batch, index, GEN8_L3SQCREG4);
-   wa_ctx_emit(batch, index, engine->scratch.gtt_offset + 256);
+   wa_ctx_emit(batch, index, engine->scratch->node.start + 256);
wa_ctx_emit(batch, index, 0);
 
wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
@@ -932,7 +932,7 @@ static inline int gen8_emit_flush_coherentl3_wa(struct 
intel_engine_cs *engine,
wa_ctx_emit(batch, index, (MI_LOAD_REGISTER_MEM_GEN8 |
   MI_SRM_LRM_GLOBAL_GTT));
wa_ctx_emit_reg(batch, index, GEN8_L3SQCREG4);
-   wa_ctx_emit(batch, index, engine->scratch.gtt_offset + 256);
+   wa_ctx_emit(batch, index, engine->scratch->node.start + 256);
wa_ctx_emit(batch, index, 0);
 
return index;
@@ -993,7 +993,7 @@ static int gen8_init_indirectctx_bb(struct intel_engine_cs 
*engine,
 
/* WaClearSlmSpaceAtContextSwitch:bdw,chv */
/* Actual scratch location is at 128 bytes offset */
-   scratch_addr = engine->scratch.gtt_offset + 2*CACHELINE_BYTES;
+   scratch_addr = engine->scratch->node.start + 2*CACHELINE_BYTES;
 
wa_ctx_emit(batch, index, GFX_OP_PIPE_CONTROL(6));
wa_ctx_emit(batch, index, (PIPE_CONTROL_FLUSH_L3 |
@@ -1072,8 +1072,8 @@ static int gen9_init_indirectctx_bb(struct 
intel_engine_cs *engine,
/* WaClearSlmSpaceAtContextSwitch:kbl */
/* Actual scratch location is at 128 bytes offset */
if (IS_KBL_REVID(dev_priv, 0, KBL_REVID_A0)) {
-   uint32_t scratch_addr
-   = engine->scratch.gtt_offset + 2*CACHELINE_BYTES;
+   uint32_t scratch_addr =
+   

[Intel-gfx] [PATCH 3/3] drm/i915: Move common seqno reset to intel_engine_cs.c

2016-08-08 Thread Chris Wilson
Since the intel_engine_init_seqno() is shared by all engine submission
backends, move it out of the legacy intel_ringbuffer.c and
into the new home for common routines, intel_engine_cs.c

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 42 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 42 -
 2 files changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1dec35441ab5..b82401849cb5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -161,6 +161,48 @@ cleanup:
return ret;
 }
 
+void intel_engine_init_seqno(struct intel_engine_cs *engine, u32 seqno)
+{
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   /* Our semaphore implementation is strictly monotonic (i.e. we proceed
+* so long as the semaphore value in the register/page is greater
+* than the sync value), so whenever we reset the seqno,
+* so long as we reset the tracking semaphore value to 0, it will
+* always be before the next request's seqno. If we don't reset
+* the semaphore value, then when the seqno moves backwards all
+* future waits will complete instantly (causing rendering corruption).
+*/
+   if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv)) {
+   I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
+   I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
+   if (HAS_VEBOX(dev_priv))
+   I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
+   }
+   if (dev_priv->semaphore_obj) {
+   struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
+   struct page *page = i915_gem_object_get_dirty_page(obj, 0);
+   void *semaphores = kmap(page);
+   memset(semaphores + GEN8_SEMAPHORE_OFFSET(engine->id, 0),
+  0, I915_NUM_ENGINES * gen8_semaphore_seqno_size);
+   kunmap(page);
+   }
+   memset(engine->semaphore.sync_seqno, 0,
+  sizeof(engine->semaphore.sync_seqno));
+
+   intel_write_status_page(engine, I915_GEM_HWS_INDEX, seqno);
+   if (engine->irq_seqno_barrier)
+   engine->irq_seqno_barrier(engine);
+   engine->last_submitted_seqno = seqno;
+
+   engine->hangcheck.seqno = seqno;
+
+   /* After manually advancing the seqno, fake the interrupt in case
+* there are any waiters for that seqno.
+*/
+   intel_engine_wakeup(engine);
+}
+
 void intel_engine_init_hangcheck(struct intel_engine_cs *engine)
 {
memset(>hangcheck, 0, sizeof(engine->hangcheck));
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index af2d81ae3e7d..3d4613673f27 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2311,48 +2311,6 @@ int intel_ring_cacheline_align(struct 
drm_i915_gem_request *req)
return 0;
 }
 
-void intel_engine_init_seqno(struct intel_engine_cs *engine, u32 seqno)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   /* Our semaphore implementation is strictly monotonic (i.e. we proceed
-* so long as the semaphore value in the register/page is greater
-* than the sync value), so whenever we reset the seqno,
-* so long as we reset the tracking semaphore value to 0, it will
-* always be before the next request's seqno. If we don't reset
-* the semaphore value, then when the seqno moves backwards all
-* future waits will complete instantly (causing rendering corruption).
-*/
-   if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv)) {
-   I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
-   I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
-   if (HAS_VEBOX(dev_priv))
-   I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
-   }
-   if (dev_priv->semaphore_obj) {
-   struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
-   struct page *page = i915_gem_object_get_dirty_page(obj, 0);
-   void *semaphores = kmap(page);
-   memset(semaphores + GEN8_SEMAPHORE_OFFSET(engine->id, 0),
-  0, I915_NUM_ENGINES * gen8_semaphore_seqno_size);
-   kunmap(page);
-   }
-   memset(engine->semaphore.sync_seqno, 0,
-  sizeof(engine->semaphore.sync_seqno));
-
-   intel_write_status_page(engine, I915_GEM_HWS_INDEX, seqno);
-   if (engine->irq_seqno_barrier)
-   engine->irq_seqno_barrier(engine);
-   engine->last_submitted_seqno = seqno;
-
-   engine->hangcheck.seqno = seqno;
-
-   /* After manually advancing the seqno, fake the interrupt in case
-* there are any waiters for that seqno.
-  

[Intel-gfx] Updated drm-intel-testing

2016-08-08 Thread Daniel Vetter
Hi all,

New -testing cycle with cool stuff:
- refactor ddi buffer programming a bit (Ville)
- large-scale renaming to untangle naming in the gem code (Chris)
- rework vma/active tracking for accurately reaping idle mappings of shared
  objects (Chris)
- misc dp sst/mst probing corner case fixes (Ville)
- tons of cleanup all around in gem
- lockless (rcu-protected) request lookup, plus use it everywhere for
  non(b)locking waits (Chris)
- pipe crc debugfs fixes (Rodrigo)
- random fixes all over

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


[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Wrap the protected active RCU dereference in a helper

2016-08-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Wrap the protected active RCU 
dereference in a helper
URL   : https://patchwork.freedesktop.org/series/10777/
State : failure

== Summary ==

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

Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-bdw-i7-5600u)
pass   -> FAIL   (ro-skl3-i5-6260u)

fi-kbl-qkkr  total:244  pass:185  dwarn:30  dfail:0   fail:2   skip:27 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:4   dfail:0   fail:2   skip:16 
ro-bdw-i7-5600u  total:240  pass:206  dwarn:0   dfail:0   fail:2   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:173  dwarn:1   dfail:0   fail:1   skip:65 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:198  dwarn:0   dfail:0   fail:1   skip:41 
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1757/

b834992 drm-intel-nightly: 2016y-08m-05d-20h-40m-44s UTC integration manifest
33b90c7 drm/i915: Don't check for idleness before retiring after a GPU hang
3869338 drm/i915: Wrap the protected active RCU dereference in a helper

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


[Intel-gfx] [PATCH v3 3/9] drm/plane-helper: Add drm_plane_helper_check_state()

2016-08-08 Thread ville . syrjala
From: Ville Syrjälä 

Add a version of drm_plane_helper_check_update() which takes a plane
state instead of having the caller pass in everything.

And to reduce code duplication, let's reimplement
drm_plane_helper_check_update() in terms of the new function, by
having a tempororary plane state on the stack.

v2: Add a note that the functions modifies the state (Chris)
v3: Fix drm_plane_helper_check_update() y coordinates (Daniel Kurtz)

Cc: Daniel Kurtz 
Cc: Chris Wilson 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Sean Paul  (v2)
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_plane_helper.c | 139 -
 include/drm/drm_plane_helper.h |   5 ++
 2 files changed, 112 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 16c4a7bd7465..0251aeec2bf3 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -108,14 +108,9 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
 }
 
 /**
- * drm_plane_helper_check_update() - Check plane update for validity
- * @plane: plane object to update
- * @crtc: owning CRTC of owning plane
- * @fb: framebuffer to flip onto plane
- * @src: source coordinates in 16.16 fixed point
- * @dest: integer destination coordinates
+ * drm_plane_helper_check_state() - Check plane state for validity
+ * @state: plane state to check
  * @clip: integer clipping coordinates
- * @rotation: plane rotation
  * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
  * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
  * @can_position: is it legal to position the plane such that it
@@ -123,10 +118,9 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
  *only be false for primary planes.
  * @can_update_disabled: can the plane be updated while the crtc
  *   is disabled?
- * @visible: output parameter indicating whether plane is still visible after
- *   clipping
  *
- * Checks that a desired plane update is valid.  Drivers that provide
+ * Checks that a desired plane update is valid, and updates various
+ * bits of derived state (clipped coordinates etc.). Drivers that provide
  * their own plane handling rather than helper-provided implementations may
  * still wish to call this function to avoid duplication of error checking
  * code.
@@ -134,29 +128,38 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
  * RETURNS:
  * Zero if update appears valid, error code on failure
  */
-int drm_plane_helper_check_update(struct drm_plane *plane,
- struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_rect *src,
- struct drm_rect *dest,
- const struct drm_rect *clip,
- unsigned int rotation,
- int min_scale,
- int max_scale,
- bool can_position,
- bool can_update_disabled,
- bool *visible)
+int drm_plane_helper_check_state(struct drm_plane_state *state,
+const struct drm_rect *clip,
+int min_scale,
+int max_scale,
+bool can_position,
+bool can_update_disabled)
 {
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_framebuffer *fb = state->fb;
+   struct drm_rect *src = >src;
+   struct drm_rect *dst = >dst;
+   unsigned int rotation = state->rotation;
int hscale, vscale;
 
+   src->x1 = state->src_x;
+   src->y1 = state->src_y;
+   src->x2 = state->src_x + state->src_w;
+   src->y2 = state->src_y + state->src_h;
+
+   dst->x1 = state->crtc_x;
+   dst->y1 = state->crtc_y;
+   dst->x2 = state->crtc_x + state->crtc_w;
+   dst->y2 = state->crtc_y + state->crtc_h;
+
if (!fb) {
-   *visible = false;
+   state->visible = false;
return 0;
}
 
/* crtc should only be NULL when disabling (i.e., !fb) */
if (WARN_ON(!crtc)) {
-   *visible = false;
+   state->visible = false;
return 0;
}
 
@@ -168,20 +171,20 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
 
/* Check scaling */
-   hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
-   vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
+   

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

2016-08-08 Thread Maarten Lankhorst
Hey,

Op 05-08-16 om 22:28 schreef ville.syrj...@linux.intel.com:
> From: Maarten Lankhorst 
>
> This function would call drm_modeset_lock_all, while the suspend/resume
> functions already have their own locking. Fix this by factoring out
> __intel_display_resume, and calling the atomic helpers for duplicating
> atomic state and disabling all crtc's during suspend.
>
> Changes since v1:
> - Deal with -EDEADLK right after lock_all and clean up calls
>   to hw readout.
> - Always take all modeset locks so updates during gpu reset are blocked.
> Changes since v2:
> - Fix deadlock in intel_update_primary_planes.
> - Move WARN_ON(EDEADLK) to __intel_display_resume.
> - pctx -> ctx
> - only call __intel_display_resume on success in intel_display_resume.
> Changes since v3:
> - Rebase on top of dev_priv -> dev change.
> - Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
> Changes since v4 [by vsyrjala]:
> - Deal with skip_intermediate_wm
> - Update comment w.r.t. mode_config.mutex vs. ->detect()
> - Rebase due to INTEL_GEN() etc.

Setting skip_intermediate_wm seems to have already been upstreamed and I missed 
it, but
this may blow up in .crtc_enable, which programs in the intermediate wm's which 
is used
until all planes are enabled.

I fear this may blow up in interesting ways. And it should probably be using
dev_priv->wm.distrust_bios_wm instead like on SKL.

~Maarten

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


Re: [Intel-gfx] [PATCH v2 3/9] drm/plane-helper: Add drm_plane_helper_check_state()

2016-08-08 Thread Ville Syrjälä
On Mon, Aug 08, 2016 at 03:29:24PM +0800, Daniel Kurtz wrote:
> Hi Ville,
> 
> Two fixes inline...
> 
> On Wed, Jul 27, 2016 at 1:34 AM,  wrote:
> >
> > From: Ville Syrjälä 
> >
> > Add a version of drm_plane_helper_check_update() which takes a plane
> > state instead of having the caller pass in everything.
> >
> > And to reduce code duplication, let's reimplement
> > drm_plane_helper_check_update() in terms of the new function, by
> > having a tempororary plane state on the stack.
> >
> > v2: Add a note that the functions modifies the state (Chris)
> >
> > Cc: Chris Wilson 
> > Signed-off-by: Ville Syrjälä 
> 
> [snip...]
> 
> > +int drm_plane_helper_check_update(struct drm_plane *plane,
> > + struct drm_crtc *crtc,
> > + struct drm_framebuffer *fb,
> > + struct drm_rect *src,
> > + struct drm_rect *dst,
> > + const struct drm_rect *clip,
> > + unsigned int rotation,
> > + int min_scale,
> > + int max_scale,
> > + bool can_position,
> > + bool can_update_disabled,
> > + bool *visible)
> > +{
> > +   struct drm_plane_state state = {
> > +   .plane = plane,
> > +   .crtc = crtc,
> > +   .fb = fb,
> > +   .src_x = src->x1,
> > +   .src_y = src->x2,
> 
> This should be:
> src->y1
> 
> > +   .src_w = drm_rect_width(src),
> > +   .src_h = drm_rect_height(src),
> > +   .crtc_x = dst->x1,
> > +   .crtc_y = dst->x2,
> 
> And this should be:
> dst->y1

Whoops. Copypaste fail, or something. Thanks for catching those.

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


  1   2   >