Re: [Intel-gfx] [PATCH 2/4] drm/i915: Relocate intel_crtc_active()

2019-11-12 Thread Lucas De Marchi
On Tue, Nov 12, 2019 at 8:38 AM Ville Syrjala
 wrote:
>
> From: Ville Syrjälä 
>
> Move intel_crtc_active() next to its only remaining
> user (pre-g4x wm code).
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 19 ---
>  drivers/gpu/drm/i915/display/intel_display.h |  1 -
>  drivers/gpu/drm/i915/intel_pm.c  | 19 +++
>  3 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 81287ff438db..e7e5497e6f2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1040,25 +1040,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state 
> *crtc_state,
>   NULL, best_clock);
>  }
>
> -bool intel_crtc_active(struct intel_crtc *crtc)
> -{
> -   /* Be paranoid as we can arrive here with only partial
> -* state retrieved from the hardware during setup.
> -*
> -* We can ditch the adjusted_mode.crtc_clock check as soon
> -* as Haswell has gained clock readout/fastboot support.
> -*
> -* We can ditch the crtc->primary->state->fb check as soon as we can
> -* properly reconstruct framebuffers.
> -*
> -* FIXME: The intel_crtc->active here should be switched to
> -* crtc->state->active once we have proper CRTC states wired up
> -* for atomic.
> -*/
> -   return crtc->active && crtc->base.primary->state->fb &&
> -   crtc->config->hw.adjusted_mode.crtc_clock;
> -}
> -
>  enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private 
> *dev_priv,
>  enum pipe pipe)
>  {
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> b/drivers/gpu/drm/i915/display/intel_display.h
> index a5ec5eeff056..d18dc260fe83 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -558,7 +558,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state 
> *crtc_state,
> struct dpll *best_clock);
>  int chv_calc_dpll_params(int refclk, struct dpll *pll_clock);
>
> -bool intel_crtc_active(struct intel_crtc *crtc);
>  bool hsw_crtc_state_ips_capable(const struct intel_crtc_state *crtc_state);
>  void hsw_enable_ips(const struct intel_crtc_state *crtc_state);
>  void hsw_disable_ips(const struct intel_crtc_state *crtc_state);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2d389e437e87..d5e9b935f4e7 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -806,6 +806,25 @@ static bool intel_wm_plane_visible(const struct 
> intel_crtc_state *crtc_state,
> return plane_state->uapi.visible;
>  }
>
> +static bool intel_crtc_active(struct intel_crtc *crtc)

maybe shouldn't have an intel_ prefix... ?

anyway

Reviewed-by: Lucas De Marchi 

Lucas De Marchi

> +{
> +   /* Be paranoid as we can arrive here with only partial
> +* state retrieved from the hardware during setup.
> +*
> +* We can ditch the adjusted_mode.crtc_clock check as soon
> +* as Haswell has gained clock readout/fastboot support.
> +*
> +* We can ditch the crtc->primary->state->fb check as soon as we can
> +* properly reconstruct framebuffers.
> +*
> +* FIXME: The intel_crtc->active here should be switched to
> +* crtc->state->active once we have proper CRTC states wired up
> +* for atomic.
> +*/
> +   return crtc->active && crtc->base.primary->state->fb &&
> +   crtc->config->hw.adjusted_mode.crtc_clock;
> +}
> +
>  static struct intel_crtc *single_enabled_crtc(struct drm_i915_private 
> *dev_priv)
>  {
> struct intel_crtc *crtc, *enabled = NULL;
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Add missing 10bpc formats

2019-11-12 Thread Kadiyala, Kishore


> -Original Message-
> From: Ville Syrjälä 
> Sent: Monday, November 11, 2019 7:34 PM
> To: Kadiyala, Kishore 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gen9: Add missing 10bpc formats
> 
> On Mon, Nov 11, 2019 at 09:22:41AM +0530, Kishore Kadiyala wrote:
> > Add 10bpc formats for gen9.
> > This patch has dependency on below patch:
> > https://patchwork.freedesktop.org/patch/335029/?series=67741=2
> >
> > Signed-off-by: Kishore Kadiyala 
> > ---
> >  drivers/gpu/drm/i915/display/intel_sprite.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index d7f71fa90659..fad73ea00992 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -2444,6 +2444,8 @@ static const u32 skl_planar_formats[] = {
> > DRM_FORMAT_ABGR,
> > DRM_FORMAT_XRGB2101010,
> > DRM_FORMAT_XBGR2101010,
> > +   DRM_FORMAT_ARGB2101010,
> > +   DRM_FORMAT_ABGR2101010,
> 
> Nope. Alpha blending is not supported with 10bpc formats on pre-icl platforms.

I have checked the capabilities for Gen9 and as you pointed Alpha is not 
supported for 10bpc formats.
This patch can be dropped.

> 
> > DRM_FORMAT_XRGB16161616F,
> > DRM_FORMAT_XBGR16161616F,
> > DRM_FORMAT_YUYV,
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Explicitly cleanup initial_plane_config

2019-11-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Explicitly cleanup 
initial_plane_config
URL   : https://patchwork.freedesktop.org/series/69355/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7320_full -> Patchwork_15235_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15235_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15235_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_15235_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_plane_scaling@pipe-c-scaler-with-rotation:
- shard-skl:  [PASS][1] -> [DMESG-WARN][2] +2 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-skl6/igt@kms_plane_scal...@pipe-c-scaler-with-rotation.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-skl5/igt@kms_plane_scal...@pipe-c-scaler-with-rotation.html

  

### Piglit changes ###

 Possible regressions 

  * spec@glsl-1.30@execution@texelfetch fs sampler1darray 1x281-501x281 (NEW):
- pig-hsw-4770r:  NOTRUN -> [FAIL][3]
   [3]: None

  
New tests
-

  New tests have been introduced between CI_DRM_7320_full and 
Patchwork_15235_full:

### New Piglit tests (1) ###

  * spec@glsl-1.30@execution@texelfetch fs sampler1darray 1x281-501x281:
- Statuses : 1 fail(s)
- Exec time: [9.36] s

  

Known issues


  Here are the changes found in Patchwork_15235_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@vcs1-hostile-preempt:
- shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#109276] / [fdo#112080]) 
+1 similar issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-iclb4/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-iclb3/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html

  * igt@gem_ctx_persistence@vecs0-mixed-process:
- shard-skl:  [PASS][6] -> [FAIL][7] ([fdo#112194])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-skl4/igt@gem_ctx_persiste...@vecs0-mixed-process.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-skl4/igt@gem_ctx_persiste...@vecs0-mixed-process.html

  * igt@gem_eio@in-flight-contexts-1us:
- shard-snb:  [PASS][8] -> [FAIL][9] ([fdo#111946])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-snb1/igt@gem_...@in-flight-contexts-1us.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-snb7/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_create@madvise:
- shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([fdo#111747]) +1 
similar issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-tglb5/igt@gem_exec_cre...@madvise.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-tglb6/igt@gem_exec_cre...@madvise.html

  * igt@gem_exec_parallel@vcs1-fds:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#112080]) +12 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-iclb1/igt@gem_exec_paral...@vcs1-fds.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-iclb5/igt@gem_exec_paral...@vcs1-fds.html

  * igt@gem_exec_schedule@pi-ringfull-bsd:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112146]) +2 similar 
issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-iclb5/igt@gem_exec_sched...@pi-ringfull-bsd.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-iclb1/igt@gem_exec_sched...@pi-ringfull-bsd.html

  * igt@gem_userptr_blits@sync-unmap-after-close:
- shard-hsw:  [PASS][16] -> [DMESG-WARN][17] ([fdo#111870]) +1 
similar issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-hsw5/igt@gem_userptr_bl...@sync-unmap-after-close.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-hsw4/igt@gem_userptr_bl...@sync-unmap-after-close.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][18] -> [DMESG-WARN][19] ([fdo#108566]) +3 
similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/shard-apl3/igt@gem_workarou...@suspend-resume-context.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/shard-apl6/igt@gem_workarou...@suspend-resume-context.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-kbl:  [PASS][20] -> [DMESG-WARN][21] ([fdo#108566]) +2 
similar issues
   [20]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/tgl: allow DVI/HDMI on port A

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: allow DVI/HDMI on port A
URL   : https://patchwork.freedesktop.org/series/69387/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7324 -> Patchwork_15247


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15247 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15247, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15247/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_15247:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_blt:
- fi-hsw-peppy:   [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7324/fi-hsw-peppy/igt@i915_selftest@live_blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15247/fi-hsw-peppy/igt@i915_selftest@live_blt.html

  
Known issues


  Here are the changes found in Patchwork_15247 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u:   [DMESG-WARN][3] ([fdo#107139]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7324/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15247/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_busy@basic-flip-pipe-a:
- fi-icl-u2:  [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7324/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15247/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343


Participating hosts (51 -> 46)
--

  Additional (1): fi-skl-6770hq 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7324 -> Patchwork_15247

  CI-20190529: 20190529
  CI_DRM_7324: dd07789205270dd69eca30ef7d123b5d2322d7a8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5274: 1345346c97c630563aae08cc2f1276c70b90378d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15247: 5569c16a4f300e07ec55ed4327423b2cdb4265f3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5569c16a4f30 drm/i915/tgl: allow DVI/HDMI on port A

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: allow DVI/HDMI on port A

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915/tgl: allow DVI/HDMI on port A
URL   : https://patchwork.freedesktop.org/series/69387/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5569c16a4f30 drm/i915/tgl: allow DVI/HDMI on port A
-:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#6: 
Tiger Lake supports HDMI on port A. For other platforms we ignore what the VBT

-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 2ba7d7e04371 ("drm/i915/bios: 
ignore HDMI on port A")'
#8: 
2ba7d7e04371 ("drm/i915/bios: ignore HDMI on port A"). Make this apply

total: 1 errors, 1 warnings, 0 checks, 16 lines checked

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

[Intel-gfx] [PATCH] drm/i915/tgl: allow DVI/HDMI on port A

2019-11-12 Thread Lucas De Marchi
Tiger Lake supports HDMI on port A. For other platforms we ignore what the VBT
says regarding HDMI to workaround broken VBTs, see commit
2ba7d7e04371 ("drm/i915/bios: ignore HDMI on port A"). Make this apply
gen12+ so they inherit the TGL behavior.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7c0ca733bef8..e6da98729e1f 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1450,7 +1450,7 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv,
is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT) 
== 0;
is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
 
-   if (port == PORT_A && is_dvi) {
+   if (port == PORT_A && is_dvi && INTEL_GEN(dev_priv) < 12) {
DRM_DEBUG_KMS("VBT claims port A supports DVI%s, ignoring\n",
  is_hdmi ? "/HDMI" : "");
is_dvi = false;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index ed4a68fb351f..659a03b08849 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3140,7 +3140,7 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
DRM_DEBUG_KMS("Adding HDMI connector on [ENCODER:%d:%s]\n",
  intel_encoder->base.base.id, intel_encoder->base.name);
 
-   if (WARN_ON(port == PORT_A))
+   if (INTEL_GEN(dev_priv) < 12 && WARN_ON(port == PORT_A))
return;
 
if (WARN(intel_dig_port->max_lanes < 4,
-- 
2.24.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix a bug calling sleep function in atomic context

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix a bug calling sleep function in atomic context
URL   : https://patchwork.freedesktop.org/series/69385/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7324 -> Patchwork_15246


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15246/index.html

Known issues


  Here are the changes found in Patchwork_15246 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy:   [PASS][1] -> [DMESG-WARN][2] ([fdo#102614])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7324/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15246/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-kbl-7500u:   [DMESG-WARN][3] ([fdo#107139]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7324/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15246/fi-kbl-7500u/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@kms_busy@basic-flip-pipe-a:
- fi-icl-u2:  [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7324/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15246/fi-icl-u2/igt@kms_b...@basic-flip-pipe-a.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-guc: [FAIL][7] ([fdo#103167]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7324/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15246/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html

  
  [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713


Participating hosts (51 -> 46)
--

  Additional (1): fi-skl-6770hq 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7324 -> Patchwork_15246

  CI-20190529: 20190529
  CI_DRM_7324: dd07789205270dd69eca30ef7d123b5d2322d7a8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5274: 1345346c97c630563aae08cc2f1276c70b90378d @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15246: 87b5c93d694e0a22a5fec76927b71215475c59ec @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

87b5c93d694e drm/i915: Fix a bug calling sleep function in atomic context

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/tgl: MOCS table update

2019-11-12 Thread Lucas De Marchi

On Tue, Nov 12, 2019 at 02:47:57PM -0800, Matt Roper wrote:

The bspec was just updated with a minor correction to entry 61 (it
shouldn't have had the SCF bit set).

v2:
- Add a MOCS_ENTRY_UNUSED() and use it to declare the
  explicitly-reserved MOCS entries. (Lucas)
- Move the warning suppression from the Makefile to a #pragma that only
  affects the TGL table. (Lucas)

v3:
- Entries 16 and 17 are identical to ICL now, so no need to explicitly
  adjust them (or mess with compiler warning overrides).

Bspec: 45101
Fixes: 2ddf992179c4 ("drm/i915/tgl: Define MOCS entries for Tigerlake")
Cc: Tomasz Lis 
Cc: Lucas De Marchi 
Cc: Francisco Jerez 
Cc: Jon Bloomfield 
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 06e2adbf27be..2b977991b785 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -263,7 +263,7 @@ static const struct drm_i915_mocs_entry 
tigerlake_mocs_table[] = {
   L3_1_UC),
/* HW Special Case (Displayable) */
MOCS_ENTRY(61,
-  LE_1_UC | LE_TC_1_LLC | LE_SCF(1),
+  LE_1_UC | LE_TC_1_LLC,
   L3_3_WB),
};

--
2.21.0


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] Revert "drm/i915/ehl: Update MOCS table for EHL"

2019-11-12 Thread Patchwork
== Series Details ==

Series: series starting with [v3,1/2] Revert "drm/i915/ehl: Update MOCS table 
for EHL"
URL   : https://patchwork.freedesktop.org/series/69383/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7323 -> Patchwork_15245


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/index.html

Known issues


  Here are the changes found in Patchwork_15245 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_blt:
- fi-bsw-nick:[PASS][1] -> [DMESG-FAIL][2] ([fdo#112176])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-bsw-nick/igt@i915_selftest@live_blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/fi-bsw-nick/igt@i915_selftest@live_blt.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#111407])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-skl-6770hq:  [PASS][5] -> [FAIL][6] ([fdo#109495])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/fi-skl-6770hq/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-copy:
- fi-glk-dsi: [INCOMPLETE][7] ([fdo#103359] / [k.org#198133]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [DMESG-WARN][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-skl-6770hq:  [DMESG-WARN][11] ([fdo#105541]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15245/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109495]: https://bugs.freedesktop.org/show_bug.cgi?id=109495
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (51 -> 46)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7323 -> Patchwork_15245

  CI-20190529: 20190529
  CI_DRM_7323: aac244f23bf1eaf986c5df9e529863b34e52bee8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5273: 602003c3d751c72fc309a0e64d4193f6da720f6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15245: 8724d17c3122a2f84c5efb4fa7e1daf6f71c247d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8724d17c3122 drm/i915/tgl: MOCS table update
642131253e70 Revert "drm/i915/ehl: Update MOCS table for EHL"

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Fix a bug calling sleep function in atomic context

2019-11-12 Thread Bruce Chang
There are quite a few reports regarding "BUG: sleeping function called from
invalid context at mm/page_alloc.c"

Basically after the io_mapping_map_atomic_wc/kmap_atomic, it enters atomic
context, but compress_page cannot be called in atomic context as it will
call pool_alloc with GFP_KERNEL flag which can go to sleep. This is why
the bug got reported.

So, changed to non atomic version instead.

Signed-off-by: Bruce Chang 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 1f2f266f26af..7118ecb7f144 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1007,67 +1007,67 @@ i915_error_object_create(struct drm_i915_private *i915,
compress->wc = i915_gem_object_is_lmem(vma->obj) ||
   drm_mm_node_allocated(>error_capture);
 
ret = -EINVAL;
if (drm_mm_node_allocated(>error_capture)) {
void __iomem *s;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
ggtt->vm.insert_page(>vm, dma, slot,
 I915_CACHE_NONE, 0);
 
s = io_mapping_map_wc(>iomap, slot, PAGE_SIZE);
ret = compress_page(compress, (void  __force *)s, dst);
io_mapping_unmap(s);
if (ret)
break;
}
} else if (i915_gem_object_is_lmem(vma->obj)) {
struct intel_memory_region *mem = vma->obj->mm.region;
dma_addr_t dma;
 
for_each_sgt_daddr(dma, iter, vma->pages) {
void __iomem *s;
 
-   s = io_mapping_map_atomic_wc(>iomap, dma);
+   s = io_mapping_map_wc(>iomap, dma, PAGE_SIZE);
ret = compress_page(compress, (void __force *)s, dst);
-   io_mapping_unmap_atomic(s);
+   io_mapping_unmap(s);
if (ret)
break;
}
} else {
struct page *page;
 
for_each_sgt_page(page, iter, vma->pages) {
void *s;
 
drm_clflush_pages(, 1);
 
-   s = kmap_atomic(page);
+   s = kmap(page);
ret = compress_page(compress, s, dst);
-   kunmap_atomic(s);
+   kunmap(s);
 
drm_clflush_pages(, 1);
 
if (ret)
break;
}
}
 
if (ret || compress_flush(compress, dst)) {
while (dst->page_count--)
pool_free(>pool, dst->pages[dst->page_count]);
kfree(dst);
dst = NULL;
}
compress_finish(compress);
 
return dst;
 }
 
 /*
  * Generate a semi-unique error code. The code is not meant to have meaning, 
The
  * code's only purpose is to try to prevent false duplicated bug reports by
  * grossly estimating a GPU error state.
  *
  * TODO Ideally, hashing the batchbuffer would be a very nice way to determine
-- 
2.24.0

___
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/vbt: Parse power conservation features block

2019-11-12 Thread Souza, Jose
On Tue, 2019-11-12 at 13:21 -0800, Matt Roper wrote:
> On Tue, Nov 05, 2019 at 05:45:04PM -0800, José Roberto de Souza
> wrote:
> > Since VBT 228 is from this block that PSR and other power saving
> > features configuration should be read from.
> > 
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_bios.c | 19 +++-
> >  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29
> > +++
> >  2 files changed, 47 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index a03f56b7b4ef..bf79e9858bd8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -561,7 +561,23 @@ parse_driver_features(struct drm_i915_private
> > *dev_priv,
> >  */
> > if (!driver->drrs_enabled)
> > dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> > -   dev_priv->vbt.psr.enable = driver->psr_enabled;
> > +   if (bdb->version < 228)
> > +   dev_priv->vbt.psr.enable = driver->psr_enabled;
> > +}
> > +
> > +static void
> > +parse_power_conservation_features(struct drm_i915_private
> > *dev_priv,
> > + const struct bdb_header *bdb)
> > +{
> > +   const struct bdb_lfp_power *power;
> > +   u8 panel_type = dev_priv->vbt.panel_type;
> > +
> > +   power = find_section(bdb, BDB_LVDS_POWER);
> > +   if (!power)
> > +   return;
> > +
> > +   if (bdb->version >= 228)
> > +   dev_priv->vbt.psr.enable = power->psr & (1 <<
> > panel_type);
> 
> Should we also be setting dev_priv->vbt.drrs_type =
> DRRS_NOT_SUPPORTED
> if block 44 tells us it isn't valid on this panel?
> 

Yep, it should.
Thanks for catching this.

> 
> Matt
> 
> >  }
> >  
> >  static void
> > @@ -1878,6 +1894,7 @@ void intel_bios_init(struct drm_i915_private
> > *dev_priv)
> > parse_lfp_backlight(dev_priv, bdb);
> > parse_sdvo_panel_data(dev_priv, bdb);
> > parse_driver_features(dev_priv, bdb);
> > +   parse_power_conservation_features(dev_priv, bdb);
> > parse_edp(dev_priv, bdb);
> > parse_psr(dev_priv, bdb);
> > parse_mipi_config(dev_priv, bdb);
> > diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > index 69a7cb1fa121..31f47ce56587 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> > @@ -792,6 +792,35 @@ struct bdb_lfp_backlight_data {
> > struct lfp_backlight_control_method backlight_control[16];
> >  } __packed;
> >  
> > +/*
> > + * Block 44 - LFP Power Conservation Features Block
> > + */
> > +
> > +struct als_data_entry {
> > +   u16 backlight_adjust;
> > +   u16 lux;
> > +} __packed;
> > +
> > +struct agressiveness_profile_entry {
> > +   u8 dpst_agressiveness : 4;
> > +   u8 lace_agressiveness : 4;
> > +} __packed;
> > +
> > +struct bdb_lfp_power {
> > +   u8 lfp_feature_bits;
> > +   struct als_data_entry als[5];
> > +   u8 lace_aggressiveness_profile;
> > +   u16 dpst;
> > +   u16 psr;
> > +   u16 drrs;
> > +   u16 lace_support;
> > +   u16 adt;
> > +   u16 dmrrs;
> > +   u16 adb;
> > +   u16 lace_enabled_status;
> > +   struct agressiveness_profile_entry aggressivenes[16];
> > +} __packed;
> > +
> >  /*
> >   * Block 52 - MIPI Configuration Block
> >   */
> > -- 
> > 2.24.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all others

2019-11-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/gt: Set unused mocs entry to follow 
PTE on tgl as on all others
URL   : https://patchwork.freedesktop.org/series/69382/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7323 -> Patchwork_15244


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15244/index.html

New tests
-

  New tests have been introduced between CI_DRM_7323 and Patchwork_15244:

### New IGT tests (1) ###

  * igt@i915_selftest@live_gt_mocs:
- Statuses : 42 pass(s)
- Exec time: [0.43, 2.95] s

  

Known issues


  Here are the changes found in Patchwork_15244 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_blt:
- fi-bsw-n3050:   [PASS][1] -> [DMESG-FAIL][2] ([fdo#112176])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-bsw-n3050/igt@i915_selftest@live_blt.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15244/fi-bsw-n3050/igt@i915_selftest@live_blt.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-skl-6770hq:  [PASS][3] -> [WARN][4] ([fdo#112252])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15244/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-copy:
- fi-glk-dsi: [INCOMPLETE][5] ([fdo#103359] / [k.org#198133]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15244/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-skl-6770hq:  [DMESG-WARN][7] ([fdo#105541]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15244/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
  [fdo#112252]: https://bugs.freedesktop.org/show_bug.cgi?id=112252
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (51 -> 46)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7323 -> Patchwork_15244

  CI-20190529: 20190529
  CI_DRM_7323: aac244f23bf1eaf986c5df9e529863b34e52bee8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5273: 602003c3d751c72fc309a0e64d4193f6da720f6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15244: eb1c77834cff62bf68581e3a84d88231eab4c5a4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

eb1c77834cff drm/i915/selftests: Add coverage of mocs registers
726603472df5 drm/i915/gt: Refactor mocs loops into single control macro
32b7d4b60407 drm/i915/gt: Tidy up debug-warns for the mocs control table
3876af3a2069 drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all 
others

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Exercise long preemption chains

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Exercise long preemption chains
URL   : https://patchwork.freedesktop.org/series/69375/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7323 -> Patchwork_15243


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15243 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15243, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15243/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_15243:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-lmem/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15243/fi-skl-lmem/igt@i915_pm_...@module-reload.html

  
Known issues


  Here are the changes found in Patchwork_15243 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-skl-6770hq:  [PASS][3] -> [WARN][4] ([fdo#112252])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15243/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-copy:
- fi-glk-dsi: [INCOMPLETE][5] ([fdo#103359] / [k.org#198133]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15243/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-skl-6770hq:  [DMESG-WARN][7] ([fdo#105541]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15243/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#112252]: https://bugs.freedesktop.org/show_bug.cgi?id=112252
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (51 -> 44)
--

  Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-bsw-kefka fi-byt-clapper 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7323 -> Patchwork_15243

  CI-20190529: 20190529
  CI_DRM_7323: aac244f23bf1eaf986c5df9e529863b34e52bee8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5273: 602003c3d751c72fc309a0e64d4193f6da720f6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15243: a2d073857c00c20fa37e78ffdfa7bd6f491f51b3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a2d073857c00 drm/i915/selftests: Exercise long preemption chains

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all others

2019-11-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/gt: Set unused mocs entry to follow 
PTE on tgl as on all others
URL   : https://patchwork.freedesktop.org/series/69382/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3876af3a2069 drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all 
others
32b7d4b60407 drm/i915/gt: Tidy up debug-warns for the mocs control table
726603472df5 drm/i915/gt: Refactor mocs loops into single control macro
-:66: CHECK:MACRO_ARG_REUSE: Macro argument reuse 't' - possible side-effects?
#66: FILE: drivers/gpu/drm/i915/gt/intel_mocs.c:345:
+#define for_each_mocs(mocs, t, i) \
+   for (i = 0; \
+i < (t)->n_entries ? (mocs = get_entry_control((t), i)), 1 : 0;\
+i++)

-:66: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i' - possible side-effects?
#66: FILE: drivers/gpu/drm/i915/gt/intel_mocs.c:345:
+#define for_each_mocs(mocs, t, i) \
+   for (i = 0; \
+i < (t)->n_entries ? (mocs = get_entry_control((t), i)), 1 : 0;\
+i++)

-:128: CHECK:MACRO_ARG_REUSE: Macro argument reuse 't' - possible side-effects?
#128: FILE: drivers/gpu/drm/i915/gt/intel_mocs.c:400:
+#define for_each_l3cc(l3cc, t, i) \
+   for (i = 0; \
+i < ((t)->n_entries + 1) / 2 ? \
+(l3cc = l3cc_combine(get_entry_l3cc((t), 2 * i), \
+ get_entry_l3cc((t), 2 * i + 1))), 1 : \
+0; \
+i++)

-:128: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i' - possible side-effects?
#128: FILE: drivers/gpu/drm/i915/gt/intel_mocs.c:400:
+#define for_each_l3cc(l3cc, t, i) \
+   for (i = 0; \
+i < ((t)->n_entries + 1) / 2 ? \
+(l3cc = l3cc_combine(get_entry_l3cc((t), 2 * i), \
+ get_entry_l3cc((t), 2 * i + 1))), 1 : \
+0; \
+i++)

total: 0 errors, 0 warnings, 4 checks, 217 lines checked
eb1c77834cff drm/i915/selftests: Add coverage of mocs registers
-:30: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#30: 
new file mode 100644

-:35: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#35: FILE: drivers/gpu/drm/i915/gt/selftest_mocs.c:1:
+/*

-:36: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use 
line 1 instead
#36: FILE: drivers/gpu/drm/i915/gt/selftest_mocs.c:2:
+ * SPDX-License-Identifier: MIT

total: 0 errors, 3 warnings, 0 checks, 433 lines checked

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/tgl: MOCS table update

2019-11-12 Thread Francisco Jerez
Matt Roper  writes:

> The bspec was just updated with a minor correction to entry 61 (it
> shouldn't have had the SCF bit set).
>
> v2:
>  - Add a MOCS_ENTRY_UNUSED() and use it to declare the
>explicitly-reserved MOCS entries. (Lucas)
>  - Move the warning suppression from the Makefile to a #pragma that only
>affects the TGL table. (Lucas)
>
> v3:
>  - Entries 16 and 17 are identical to ICL now, so no need to explicitly
>adjust them (or mess with compiler warning overrides).
>
> Bspec: 45101
> Fixes: 2ddf992179c4 ("drm/i915/tgl: Define MOCS entries for Tigerlake")
> Cc: Tomasz Lis 
> Cc: Lucas De Marchi 
> Cc: Francisco Jerez 
> Cc: Jon Bloomfield 
> Signed-off-by: Matt Roper 

Reviewed-by: Francisco Jerez 

> ---
>  drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 06e2adbf27be..2b977991b785 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -263,7 +263,7 @@ static const struct drm_i915_mocs_entry 
> tigerlake_mocs_table[] = {
>  L3_1_UC),
>   /* HW Special Case (Displayable) */
>   MOCS_ENTRY(61,
> -LE_1_UC | LE_TC_1_LLC | LE_SCF(1),
> +LE_1_UC | LE_TC_1_LLC,
>  L3_3_WB),
>  };
>  
> -- 
> 2.21.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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 v3 1/2] Revert "drm/i915/ehl: Update MOCS table for EHL"

2019-11-12 Thread Francisco Jerez
Matt Roper  writes:

> This reverts commit f4071997f1de016780ec6b79c63d90cd5886ee83.
>
> These extra EHL entries won't behave as expected without a bit more work
> on the kernel side so let's drop them until that kernel work has had a
> chance to land.  Userspace trying to use these new entries won't get the
> advantage of the new functionality these entries are meant to provide,
> but at least it won't misbehave.
>
> When we do add these back in the future, we'll probably want to
> explicitly use separate tables for ICL and EHL so that userspace
> software that mistakenly uses these entries (which are undefined on ICL)
> sees the same behavior it sees with all the other undefined entries.
>
> Cc: Francisco Jerez 
> Cc: Jon Bloomfield 
> Cc: Lucas De Marchi 
> Signed-off-by: Matt Roper 

I think f4071997f1de016780ec6b79c63d90cd5886ee83 has hit a few kernel
releases already.  Wouldn't it make sense to CC stable?

Patch is:

Reviewed-by: Francisco Jerez 

> ---
>  drivers/gpu/drm/i915/gt/intel_mocs.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 6e881c735b20..06e2adbf27be 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -200,14 +200,6 @@ static const struct drm_i915_mocs_entry 
> broxton_mocs_table[] = {
>   MOCS_ENTRY(15, \
>  LE_3_WB | LE_TC_1_LLC | LE_LRUM(2) | LE_AOM(1), \
>  L3_3_WB), \
> - /* Bypass LLC - Uncached (EHL+) */ \
> - MOCS_ENTRY(16, \
> -LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
> -L3_1_UC), \
> - /* Bypass LLC - L3 (Read-Only) (EHL+) */ \
> - MOCS_ENTRY(17, \
> -LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
> -L3_3_WB), \
>   /* Self-Snoop - L3 + LLC */ \
>   MOCS_ENTRY(18, \
>  LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_SSE(3), \
> -- 
> 2.21.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flush all user surfaces prior to first use (rev5)

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Flush all user surfaces prior to first use (rev5)
URL   : https://patchwork.freedesktop.org/series/63871/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7323 -> Patchwork_15242


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15242 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15242, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15242/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_15242:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-lmem/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15242/fi-skl-lmem/igt@i915_pm_...@module-reload.html

  
Known issues


  Here are the changes found in Patchwork_15242 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-skl-6770hq:  [PASS][3] -> [WARN][4] ([fdo#112252])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15242/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-copy:
- fi-glk-dsi: [INCOMPLETE][5] ([fdo#103359] / [k.org#198133]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15242/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [DMESG-WARN][7] -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15242/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-skl-6770hq:  [DMESG-WARN][9] ([fdo#105541]) -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15242/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#112252]: https://bugs.freedesktop.org/show_bug.cgi?id=112252
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (51 -> 45)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-skl-6600u 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7323 -> Patchwork_15242

  CI-20190529: 20190529
  CI_DRM_7323: aac244f23bf1eaf986c5df9e529863b34e52bee8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5273: 602003c3d751c72fc309a0e64d4193f6da720f6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15242: 829ff143a5ba63f512dbf54193c62044e9ff09e7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

829ff143a5ba drm/i915: Flush all user surfaces prior to first use

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Exercise long preemption chains

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Exercise long preemption chains
URL   : https://patchwork.freedesktop.org/series/69375/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a2d073857c00 drm/i915/selftests: Exercise long preemption chains
-:134: WARNING:LINE_SPACING: Missing a blank line after declarations
#134: FILE: drivers/gpu/drm/i915/gt/selftest_lrc.c:2032:
+   struct igt_live_test t;
+   IGT_TIMEOUT(end_time);

total: 0 errors, 1 warnings, 0 checks, 198 lines checked

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

[Intel-gfx] [PATCH v3 1/2] Revert "drm/i915/ehl: Update MOCS table for EHL"

2019-11-12 Thread Matt Roper
This reverts commit f4071997f1de016780ec6b79c63d90cd5886ee83.

These extra EHL entries won't behave as expected without a bit more work
on the kernel side so let's drop them until that kernel work has had a
chance to land.  Userspace trying to use these new entries won't get the
advantage of the new functionality these entries are meant to provide,
but at least it won't misbehave.

When we do add these back in the future, we'll probably want to
explicitly use separate tables for ICL and EHL so that userspace
software that mistakenly uses these entries (which are undefined on ICL)
sees the same behavior it sees with all the other undefined entries.

Cc: Francisco Jerez 
Cc: Jon Bloomfield 
Cc: Lucas De Marchi 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 6e881c735b20..06e2adbf27be 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -200,14 +200,6 @@ static const struct drm_i915_mocs_entry 
broxton_mocs_table[] = {
MOCS_ENTRY(15, \
   LE_3_WB | LE_TC_1_LLC | LE_LRUM(2) | LE_AOM(1), \
   L3_3_WB), \
-   /* Bypass LLC - Uncached (EHL+) */ \
-   MOCS_ENTRY(16, \
-  LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
-  L3_1_UC), \
-   /* Bypass LLC - L3 (Read-Only) (EHL+) */ \
-   MOCS_ENTRY(17, \
-  LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
-  L3_3_WB), \
/* Self-Snoop - L3 + LLC */ \
MOCS_ENTRY(18, \
   LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_SSE(3), \
-- 
2.21.0

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

[Intel-gfx] [PATCH v3 2/2] drm/i915/tgl: MOCS table update

2019-11-12 Thread Matt Roper
The bspec was just updated with a minor correction to entry 61 (it
shouldn't have had the SCF bit set).

v2:
 - Add a MOCS_ENTRY_UNUSED() and use it to declare the
   explicitly-reserved MOCS entries. (Lucas)
 - Move the warning suppression from the Makefile to a #pragma that only
   affects the TGL table. (Lucas)

v3:
 - Entries 16 and 17 are identical to ICL now, so no need to explicitly
   adjust them (or mess with compiler warning overrides).

Bspec: 45101
Fixes: 2ddf992179c4 ("drm/i915/tgl: Define MOCS entries for Tigerlake")
Cc: Tomasz Lis 
Cc: Lucas De Marchi 
Cc: Francisco Jerez 
Cc: Jon Bloomfield 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 06e2adbf27be..2b977991b785 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -263,7 +263,7 @@ static const struct drm_i915_mocs_entry 
tigerlake_mocs_table[] = {
   L3_1_UC),
/* HW Special Case (Displayable) */
MOCS_ENTRY(61,
-  LE_1_UC | LE_TC_1_LLC | LE_SCF(1),
+  LE_1_UC | LE_TC_1_LLC,
   L3_3_WB),
 };
 
-- 
2.21.0

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

[Intel-gfx] [PATCH 1/4] drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all others

2019-11-12 Thread Chris Wilson
Be consistent in our mocs setup on Tigerlake and set the unused control
value to follow the PTE entry as we previously have done. The unused
values are beyond the defines of the ABI, the consistency simplifies our
checking.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 6e881c735b20..d2b445d6c258 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -489,7 +489,7 @@ static void intel_mocs_init_global(struct intel_gt *gt)
for (; index < table.n_entries; index++)
intel_uncore_write(uncore,
   GEN12_GLOBAL_MOCS(index),
-  table.table[0].control_value);
+  table.table[I915_MOCS_PTE].control_value);
 }
 
 void intel_mocs_init(struct intel_gt *gt)
-- 
2.24.0

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

[Intel-gfx] [PATCH 4/4] drm/i915/selftests: Add coverage of mocs registers

2019-11-12 Thread Chris Wilson
Probe the mocs registers for new contexts and across GPU resets. Similar
to intel_workarounds, we have tables of what register values we expect
to see, so verify that user contexts are affected by them. In the
future, we should add tests similar to intel_sseu to cover dynamic
reconfigurations.

Signed-off-by: Chris Wilson 
Cc: Prathap Kumar Valsan 
Cc: Mika Kuoppala 
Reviewed-by: Prathap Kumar Valsan 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c  |   4 +
 drivers/gpu/drm/i915/gt/selftest_mocs.c   | 419 ++
 .../drm/i915/selftests/i915_live_selftests.h  |   1 +
 3 files changed, 424 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gt/selftest_mocs.c

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 47d16a242183..7f292aacaa81 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -460,3 +460,7 @@ void intel_mocs_init(struct intel_gt *gt)
if (HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
init_global_mocs(gt);
 }
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "selftest_mocs.c"
+#endif
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c 
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
new file mode 100644
index ..a34d4fb52fa1
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -0,0 +1,419 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gt/intel_engine_pm.h"
+#include "i915_selftest.h"
+
+#include "gem/selftests/mock_context.h"
+#include "selftests/igt_reset.h"
+#include "selftests/igt_spinner.h"
+
+struct live_mocs {
+   struct drm_i915_mocs_table table;
+   struct i915_vma *scratch;
+   void *vaddr;
+};
+
+static int request_add_sync(struct i915_request *rq, int err)
+{
+   i915_request_get(rq);
+   i915_request_add(rq);
+   if (i915_request_wait(rq, 0, HZ / 5) < 0)
+   err = -ETIME;
+   i915_request_put(rq);
+
+   return err;
+}
+
+static int request_add_spin(struct i915_request *rq, struct igt_spinner *spin)
+{
+   int err = 0;
+
+   i915_request_get(rq);
+   i915_request_add(rq);
+   if (spin && !igt_wait_for_spinner(spin, rq))
+   err = -ETIME;
+   i915_request_put(rq);
+
+   return err;
+}
+
+static struct i915_vma *create_scratch(struct intel_gt *gt)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int err;
+
+   obj = i915_gem_object_create_internal(gt->i915, PAGE_SIZE);
+   if (IS_ERR(obj))
+   return ERR_CAST(obj);
+
+   i915_gem_object_set_cache_coherency(obj, I915_CACHING_CACHED);
+
+   vma = i915_vma_instance(obj, >ggtt->vm, NULL);
+   if (IS_ERR(vma)) {
+   i915_gem_object_put(obj);
+   return vma;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, PIN_GLOBAL);
+   if (err) {
+   i915_gem_object_put(obj);
+   return ERR_PTR(err);
+   }
+
+   return vma;
+}
+
+static int live_mocs_init(struct live_mocs *arg, struct intel_gt *gt)
+{
+   int err;
+
+   if (!get_mocs_settings(gt->i915, >table))
+   return -EINVAL;
+
+   arg->scratch = create_scratch(gt);
+   if (IS_ERR(arg->scratch))
+   return PTR_ERR(arg->scratch);
+
+   arg->vaddr = i915_gem_object_pin_map(arg->scratch->obj, I915_MAP_WB);
+   if (IS_ERR(arg->vaddr)) {
+   err = PTR_ERR(arg->vaddr);
+   goto err_scratch;
+   }
+
+   return 0;
+
+err_scratch:
+   i915_vma_unpin_and_release(>scratch, 0);
+   return err;
+}
+
+static void live_mocs_fini(struct live_mocs *arg)
+{
+   i915_vma_unpin_and_release(>scratch, I915_VMA_RELEASE_MAP);
+}
+
+static int read_regs(struct i915_request *rq,
+u32 addr, unsigned int count,
+uint32_t *offset)
+{
+   unsigned int i;
+   u32 *cs;
+
+   GEM_BUG_ON(!IS_ALIGNED(*offset, sizeof(u32)));
+
+   cs = intel_ring_begin(rq, 4 * count);
+   if (IS_ERR(cs))
+   return PTR_ERR(cs);
+
+   for (i = 0; i < count; i++) {
+   *cs++ = MI_STORE_REGISTER_MEM_GEN8 | MI_USE_GGTT;
+   *cs++ = addr;
+   *cs++ = *offset;
+   *cs++ = 0;
+
+   addr += sizeof(u32);
+   *offset += sizeof(u32);
+   }
+
+   intel_ring_advance(rq, cs);
+
+   return 0;
+}
+
+static int read_mocs_table(struct i915_request *rq,
+  const struct drm_i915_mocs_table *table,
+  uint32_t *offset)
+{
+   u32 addr;
+
+   if (HAS_GLOBAL_MOCS_REGISTERS(rq->i915))
+   addr = global_mocs_offset();
+   else
+   addr = mocs_offset(rq->engine);
+
+   return read_regs(rq, addr, table->n_entries, offset);
+}
+
+static int read_l3cc_table(struct i915_request *rq,
+  const struct drm_i915_mocs_table *table,
+   

[Intel-gfx] [PATCH 3/4] drm/i915/gt: Refactor mocs loops into single control macro

2019-11-12 Thread Chris Wilson
We repeatedly (and more so in future) use the same looping construct
over the mocs definition table to setup the register state. Refactor the
loop construct into a reusable macro.

add/remove: 2/1 grow/shrink: 1/2 up/down: 113/-330 (-217)
Function old new   delta
intel_mocs_init_engine.cold-  71 +71
offset -  28 +28
__func__   17273   17287 +14
intel_mocs_init  143 113 -30
mocs_register.isra91   - -91
intel_mocs_init_engine   503 294-209

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 133 +++
 drivers/gpu/drm/i915/i915_reg.h  |  19 ++--
 2 files changed, 64 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index e6f3f36a3988..47d16a242183 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -329,27 +329,6 @@ static bool get_mocs_settings(const struct 
drm_i915_private *i915,
return true;
 }
 
-static i915_reg_t mocs_register(const struct intel_engine_cs *engine, int 
index)
-{
-   switch (engine->id) {
-   case RCS0:
-   return GEN9_GFX_MOCS(index);
-   case VCS0:
-   return GEN9_MFX0_MOCS(index);
-   case BCS0:
-   return GEN9_BLT_MOCS(index);
-   case VECS0:
-   return GEN9_VEBOX_MOCS(index);
-   case VCS1:
-   return GEN9_MFX1_MOCS(index);
-   case VCS2:
-   return GEN11_MFX2_MOCS(index);
-   default:
-   MISSING_CASE(engine->id);
-   return INVALID_MMIO_REG;
-   }
-}
-
 /*
  * Get control_value from MOCS entry taking into account when it's not used:
  * I915_MOCS_PTE's value is returned in this case.
@@ -357,29 +336,47 @@ static i915_reg_t mocs_register(const struct 
intel_engine_cs *engine, int index)
 static u32 get_entry_control(const struct drm_i915_mocs_table *table,
 unsigned int index)
 {
-   if (table->table[index].used)
+   if (index < table->size && table->table[index].used)
return table->table[index].control_value;
 
return table->table[I915_MOCS_PTE].control_value;
 }
 
-static void init_mocs_table(struct intel_engine_cs *engine,
-   const struct drm_i915_mocs_table *table)
+#define for_each_mocs(mocs, t, i) \
+   for (i = 0; \
+i < (t)->n_entries ? (mocs = get_entry_control((t), i)), 1 : 0;\
+i++)
+
+static void __init_mocs_table(struct intel_uncore *uncore,
+ const struct drm_i915_mocs_table *table,
+ u32 addr)
 {
-   struct intel_uncore *uncore = engine->uncore;
-   u32 unused_value = table->table[I915_MOCS_PTE].control_value;
unsigned int i;
+   u32 mocs;
 
-   for (i = 0; i < table->size; i++)
-   intel_uncore_write_fw(uncore,
- mocs_register(engine, i),
- get_entry_control(table, i));
+   for_each_mocs(mocs, table, i)
+   intel_uncore_write_fw(uncore, _MMIO(addr + i * 4), mocs);
+}
+
+static u32 mocs_offset(const struct intel_engine_cs *engine)
+{
+   static const u32 offset[] = {
+   [RCS0]  =  __GEN9_RCS0_MOCS0,
+   [VCS0]  =  __GEN9_VCS0_MOCS0,
+   [VCS1]  =  __GEN9_VCS1_MOCS0,
+   [VECS0] =  __GEN9_VECS0_MOCS0,
+   [BCS0]  =  __GEN9_BCS0_MOCS0,
+   [VCS2]  = __GEN11_VCS2_MOCS0,
+   };
+
+   GEM_BUG_ON(engine->id >= ARRAY_SIZE(offset));
+   return offset[engine->id];
+}
 
-   /* All remaining entries are unused */
-   for (; i < table->n_entries; i++)
-   intel_uncore_write_fw(uncore,
- mocs_register(engine, i),
- unused_value);
+static void init_mocs_table(struct intel_engine_cs *engine,
+   const struct drm_i915_mocs_table *table)
+{
+   __init_mocs_table(engine->uncore, table, mocs_offset(engine));
 }
 
 /*
@@ -389,7 +386,7 @@ static void init_mocs_table(struct intel_engine_cs *engine,
 static u16 get_entry_l3cc(const struct drm_i915_mocs_table *table,
  unsigned int index)
 {
-   if (table->table[index].used)
+   if (index < table->size && table->table[index].used)
return table->table[index].l3cc_value;
 
return table->table[I915_MOCS_PTE].l3cc_value;
@@ -400,37 +397,23 @@ static inline u32 l3cc_combine(u16 low, u16 high)
return low | (u32)high << 16;
 }
 
+#define for_each_l3cc(l3cc, t, i) \
+   for (i = 0; \
+i < ((t)->n_entries + 1) / 2 ? \
+

[Intel-gfx] [PATCH 2/4] drm/i915/gt: Tidy up debug-warns for the mocs control table

2019-11-12 Thread Chris Wilson
As we always run new platforms through CI, we only need the debug code
compiled in during CI runs.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_mocs.c | 30 ++--
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index d2b445d6c258..e6f3f36a3988 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -291,44 +291,42 @@ static const struct drm_i915_mocs_entry 
icelake_mocs_table[] = {
 static bool get_mocs_settings(const struct drm_i915_private *i915,
  struct drm_i915_mocs_table *table)
 {
-   bool result = false;
-
if (INTEL_GEN(i915) >= 12) {
table->size  = ARRAY_SIZE(tigerlake_mocs_table);
table->table = tigerlake_mocs_table;
table->n_entries = GEN11_NUM_MOCS_ENTRIES;
-   result = true;
} else if (IS_GEN(i915, 11)) {
table->size  = ARRAY_SIZE(icelake_mocs_table);
table->table = icelake_mocs_table;
table->n_entries = GEN11_NUM_MOCS_ENTRIES;
-   result = true;
} else if (IS_GEN9_BC(i915) || IS_CANNONLAKE(i915)) {
table->size  = ARRAY_SIZE(skylake_mocs_table);
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = skylake_mocs_table;
-   result = true;
} else if (IS_GEN9_LP(i915)) {
table->size  = ARRAY_SIZE(broxton_mocs_table);
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = broxton_mocs_table;
-   result = true;
} else {
WARN_ONCE(INTEL_GEN(i915) >= 9,
  "Platform that should have a MOCS table does not.\n");
+   return false;
}
 
+   if (GEM_DEBUG_WARN_ON(table->size > table->n_entries))
+   return false;
+
/* WaDisableSkipCaching:skl,bxt,kbl,glk */
if (IS_GEN(i915, 9)) {
int i;
 
for (i = 0; i < table->size; i++)
-   if (WARN_ON(table->table[i].l3cc_value &
-   (L3_ESC(1) | L3_SCC(0x7
+   if (GEM_DEBUG_WARN_ON(table->table[i].l3cc_value &
+ (L3_ESC(1) | L3_SCC(0x7
return false;
}
 
-   return result;
+   return true;
 }
 
 static i915_reg_t mocs_register(const struct intel_engine_cs *engine, int 
index)
@@ -397,9 +395,7 @@ static u16 get_entry_l3cc(const struct drm_i915_mocs_table 
*table,
return table->table[I915_MOCS_PTE].l3cc_value;
 }
 
-static inline u32 l3cc_combine(const struct drm_i915_mocs_table *table,
-  u16 low,
-  u16 high)
+static inline u32 l3cc_combine(u16 low, u16 high)
 {
return low | (u32)high << 16;
 }
@@ -417,7 +413,7 @@ static void init_l3cc_table(struct intel_engine_cs *engine,
 
intel_uncore_write(uncore,
   GEN9_LNCFCMOCS(i),
-  l3cc_combine(table, low, high));
+  l3cc_combine(low, high));
}
 
/* Odd table size - 1 left over */
@@ -426,7 +422,7 @@ static void init_l3cc_table(struct intel_engine_cs *engine,
 
intel_uncore_write(uncore,
   GEN9_LNCFCMOCS(i),
-  l3cc_combine(table, low, unused_value));
+  l3cc_combine(low, unused_value));
i++;
}
 
@@ -434,8 +430,7 @@ static void init_l3cc_table(struct intel_engine_cs *engine,
for (; i < table->n_entries / 2; i++)
intel_uncore_write(uncore,
   GEN9_LNCFCMOCS(i),
-  l3cc_combine(table, unused_value,
-   unused_value));
+  l3cc_combine(unused_value, unused_value));
 }
 
 void intel_mocs_init_engine(struct intel_engine_cs *engine)
@@ -473,9 +468,6 @@ static void intel_mocs_init_global(struct intel_gt *gt)
if (!get_mocs_settings(gt->i915, ))
return;
 
-   if (GEM_DEBUG_WARN_ON(table.size > table.n_entries))
-   return;
-
for (index = 0; index < table.size; index++)
intel_uncore_write(uncore,
   GEN12_GLOBAL_MOCS(index),
-- 
2.24.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/fbc: Nuke bogus single pipe fbc1 restriction

2019-11-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/fbc: Nuke bogus single pipe fbc1 
restriction
URL   : https://patchwork.freedesktop.org/series/69366/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7323 -> Patchwork_15241


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15241/index.html

Known issues


  Here are the changes found in Patchwork_15241 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_busy@basic-flip-pipe-b:
- fi-skl-6770hq:  [PASS][1] -> [DMESG-WARN][2] ([fdo#105541])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_b...@basic-flip-pipe-b.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15241/fi-skl-6770hq/igt@kms_b...@basic-flip-pipe-b.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15241/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-copy:
- fi-glk-dsi: [INCOMPLETE][5] ([fdo#103359] / [k.org#198133]) -> 
[PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15241/fi-glk-dsi/igt@gem_mmap_...@basic-copy.html

  * igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-skl-6770hq:  [DMESG-WARN][7] ([fdo#105541]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7323/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15241/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (51 -> 46)
--

  Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7323 -> Patchwork_15241

  CI-20190529: 20190529
  CI_DRM_7323: aac244f23bf1eaf986c5df9e529863b34e52bee8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5273: 602003c3d751c72fc309a0e64d4193f6da720f6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15241: f783f15d590106ebbbc9e7ba64b3fa8519b00c4a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f783f15d5901 drm/i915: Pass cpu transcoder to assert_pipe()
c805924f6a73 drm/i915: ELiminate intel_pipe_to_cpu_transcoder() from 
assert_fdi_tx()
aea2d6ba7337 drm/i915: Relocate intel_crtc_active()
d8e3b4babc16 drm/i915/fbc: Nuke bogus single pipe fbc1 restriction

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/fbc: Nuke bogus single pipe fbc1 restriction

2019-11-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915/fbc: Nuke bogus single pipe fbc1 
restriction
URL   : https://patchwork.freedesktop.org/series/69366/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/fbc: Nuke bogus single pipe fbc1 restriction
Okay!

Commit: drm/i915: Relocate intel_crtc_active()
Okay!

Commit: drm/i915: ELiminate intel_pipe_to_cpu_transcoder() from assert_fdi_tx()
Okay!

Commit: drm/i915: Pass cpu transcoder to assert_pipe()
+drivers/gpu/drm/i915/display/intel_dp.c:3040:9: int enum pipe versus
+drivers/gpu/drm/i915/display/intel_dp.c:3040:9: int enum transcoder
+drivers/gpu/drm/i915/display/intel_dp.c:3040:9: warning: mixing different enum 
types
+drivers/gpu/drm/i915/display/intel_dp.c:3080:9: int enum pipe versus
+drivers/gpu/drm/i915/display/intel_dp.c:3080:9: int enum transcoder
+drivers/gpu/drm/i915/display/intel_dp.c:3080:9: warning: mixing different enum 
types
+drivers/gpu/drm/i915/display/intel_tv.c:1530:9: int enum pipe versus
+drivers/gpu/drm/i915/display/intel_tv.c:1530:9: int enum transcoder
+drivers/gpu/drm/i915/display/intel_tv.c:1530:9: warning: mixing different enum 
types

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

Re: [Intel-gfx] [PATCH v2] drm/fbdev: Fallback to non tiled mode if all tiles not present

2019-11-12 Thread Dave Airlie
LGTM, thanks,

Reviewed-by: Dave Airlie 

On Sat, 9 Nov 2019 at 10:52, Manasi Navare  wrote:
>
> In case of tiled displays, if we hotplug just one connector,
> fbcon currently just selects the preferred mode and if it is
> tiled mode then that becomes a problem if rest of the tiles are
> not present.
> So in the fbdev driver on hotplug when we probe the client modeset,
> if we dont find all the connectors for all tiles, then on a connector
> with one tile, just fallback to the first available non tiled mode
> to display over a single connector.
> On the hotplug of the consecutive tiled connectors, if the tiled mode
> no longer exists because of fbcon size limitation, then return
> no modes for consecutive tiles but retain the non tiled mode
> on the 0th tile.
> Use the same logic in case of connected boot case as well.
> This has been tested with Dell UP328K tiled monitor.
>
> v2:
> * Set the modes on consecutive hotplugged tiles to no mode
> if tiled mode is pruned (Dave)
> v1:
> * Just handle the 1st connector hotplug case
> * v1 Reviewed-by: Dave Airlie 
>
> Suggested-by: Ville Syrjälä 
> Suggested-by: Dave Airlie 
> Cc: Ville Syrjälä 
> Cc: Dave Airlie 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_client_modeset.c | 70 
>  1 file changed, 70 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c 
> b/drivers/gpu/drm/drm_client_modeset.c
> index 895b73f23079..f2150a0bac4c 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -114,6 +114,33 @@ drm_client_find_modeset(struct drm_client_dev *client, 
> struct drm_crtc *crtc)
> return NULL;
>  }
>
> +static struct drm_display_mode *
> +drm_connector_get_tiled_mode(struct drm_connector *connector)
> +{
> +   struct drm_display_mode *mode;
> +
> +   list_for_each_entry(mode, >modes, head) {
> +   if (mode->hdisplay == connector->tile_h_size &&
> +   mode->vdisplay == connector->tile_v_size)
> +   return mode;
> +   }
> +   return NULL;
> +}
> +
> +static struct drm_display_mode *
> +drm_connector_fallback_non_tiled_mode(struct drm_connector *connector)
> +{
> +   struct drm_display_mode *mode;
> +
> +   list_for_each_entry(mode, >modes, head) {
> +   if (mode->hdisplay == connector->tile_h_size &&
> +   mode->vdisplay == connector->tile_v_size)
> +   continue;
> +   return mode;
> +   }
> +   return NULL;
> +}
> +
>  static struct drm_display_mode *
>  drm_connector_has_preferred_mode(struct drm_connector *connector, int width, 
> int height)
>  {
> @@ -348,8 +375,14 @@ static bool drm_client_target_preferred(struct 
> drm_connector **connectors,
> struct drm_connector *connector;
> u64 conn_configured = 0;
> int tile_pass = 0;
> +   int num_tiled_conns = 0;
> int i;
>
> +   for (i = 0; i < connector_count; i++) {
> +   if (connectors[i]->has_tile)
> +   num_tiled_conns++;
> +   }
> +
>  retry:
> for (i = 0; i < connector_count; i++) {
> connector = connectors[i];
> @@ -399,6 +432,28 @@ static bool drm_client_target_preferred(struct 
> drm_connector **connectors,
> list_for_each_entry(modes[i], >modes, head)
> break;
> }
> +   /*
> +* In case of tiled mode if all tiles not present fallback to
> +* first available non tiled mode.
> +* After all tiles are present, try to find the tiled mode
> +* for all and if tiled mode not present due to fbcon size
> +* limitations, use first non tiled mode only for
> +* tile 0,0 and set to no mode for all other tiles.
> +*/
> +   if (connector->has_tile) {
> +   if (num_tiled_conns <
> +   connector->num_h_tile * connector->num_v_tile ||
> +   (connector->tile_h_loc == 0 &&
> +connector->tile_v_loc == 0 &&
> +!drm_connector_get_tiled_mode(connector))) {
> +   DRM_DEBUG_KMS("Falling back to non tiled mode 
> on Connector %d\n",
> + connector->base.id);
> +   modes[i] = 
> drm_connector_fallback_non_tiled_mode(connector);
> +   } else {
> +   modes[i] = 
> drm_connector_get_tiled_mode(connector);
> +   }
> +   }
> +
> DRM_DEBUG_KMS("found mode %s\n", modes[i] ? modes[i]->name :
>   "none");
> conn_configured |= BIT_ULL(i);
> @@ -515,6 +570,7 @@ static bool drm_client_firmware_config(struct 
> drm_client_dev *client,
>  

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Remove unused local variable 'file'

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Remove unused local variable 'file'
URL   : https://patchwork.freedesktop.org/series/69365/
State : failure

== Summary ==

Applying: drm/i915/selftests: Remove unused local variable 'file'
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: More delays for gen7 flushing (rev2)

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: More delays for gen7 flushing (rev2)
URL   : https://patchwork.freedesktop.org/series/69360/
State : failure

== Summary ==

Applying: drm/i915/gt: Flush gen7 even harder
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gt/intel_ring_submission.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

___
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/vbt: Parse power conservation features block

2019-11-12 Thread Matt Roper
On Tue, Nov 05, 2019 at 05:45:04PM -0800, José Roberto de Souza wrote:
> Since VBT 228 is from this block that PSR and other power saving
> features configuration should be read from.
> 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 19 +++-
>  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 29 +++
>  2 files changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index a03f56b7b4ef..bf79e9858bd8 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -561,7 +561,23 @@ parse_driver_features(struct drm_i915_private *dev_priv,
>*/
>   if (!driver->drrs_enabled)
>   dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
> - dev_priv->vbt.psr.enable = driver->psr_enabled;
> + if (bdb->version < 228)
> + dev_priv->vbt.psr.enable = driver->psr_enabled;
> +}
> +
> +static void
> +parse_power_conservation_features(struct drm_i915_private *dev_priv,
> +   const struct bdb_header *bdb)
> +{
> + const struct bdb_lfp_power *power;
> + u8 panel_type = dev_priv->vbt.panel_type;
> +
> + power = find_section(bdb, BDB_LVDS_POWER);
> + if (!power)
> + return;
> +
> + if (bdb->version >= 228)
> + dev_priv->vbt.psr.enable = power->psr & (1 << panel_type);

Should we also be setting dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED
if block 44 tells us it isn't valid on this panel?


Matt

>  }
>  
>  static void
> @@ -1878,6 +1894,7 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
>   parse_lfp_backlight(dev_priv, bdb);
>   parse_sdvo_panel_data(dev_priv, bdb);
>   parse_driver_features(dev_priv, bdb);
> + parse_power_conservation_features(dev_priv, bdb);
>   parse_edp(dev_priv, bdb);
>   parse_psr(dev_priv, bdb);
>   parse_mipi_config(dev_priv, bdb);
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h 
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 69a7cb1fa121..31f47ce56587 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -792,6 +792,35 @@ struct bdb_lfp_backlight_data {
>   struct lfp_backlight_control_method backlight_control[16];
>  } __packed;
>  
> +/*
> + * Block 44 - LFP Power Conservation Features Block
> + */
> +
> +struct als_data_entry {
> + u16 backlight_adjust;
> + u16 lux;
> +} __packed;
> +
> +struct agressiveness_profile_entry {
> + u8 dpst_agressiveness : 4;
> + u8 lace_agressiveness : 4;
> +} __packed;
> +
> +struct bdb_lfp_power {
> + u8 lfp_feature_bits;
> + struct als_data_entry als[5];
> + u8 lace_aggressiveness_profile;
> + u16 dpst;
> + u16 psr;
> + u16 drrs;
> + u16 lace_support;
> + u16 adt;
> + u16 dmrrs;
> + u16 adb;
> + u16 lace_enabled_status;
> + struct agressiveness_profile_entry aggressivenes[16];
> +} __packed;
> +
>  /*
>   * Block 52 - MIPI Configuration Block
>   */
> -- 
> 2.24.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/selftests: Exercise long preemption chains

2019-11-12 Thread Chris Wilson
Verify that we can execute a long chain of dependent requests from
userspace, each one slightly more important than the last.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/selftest_lrc.c | 186 +
 1 file changed, 186 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c 
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index d1ed3c0f851c..0b0316159ae3 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1915,6 +1915,191 @@ static int live_chain_preempt(void *arg)
goto err_client_lo;
 }
 
+static int create_gang(struct intel_engine_cs *engine,
+  struct i915_request **prev)
+{
+   struct drm_i915_gem_object *obj;
+   struct intel_context *ce;
+   struct i915_request *rq;
+   struct i915_vma *vma;
+   u32 *cs;
+   int err;
+
+   ce = intel_context_create(engine->kernel_context->gem_context, engine);
+   if (IS_ERR(ce))
+   return PTR_ERR(ce);
+
+   obj = i915_gem_object_create_internal(engine->i915, 4096);
+   if (IS_ERR(obj)) {
+   err = PTR_ERR(obj);
+   goto err_ce;
+   }
+
+   vma = i915_vma_instance(obj, ce->vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_obj;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, PIN_USER);
+   if (err)
+   goto err_obj;
+
+   cs = i915_gem_object_pin_map(obj, I915_MAP_WC);
+   if (IS_ERR(cs))
+   goto err_obj;
+
+   *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+
+   *cs++ = MI_SEMAPHORE_WAIT |
+   MI_SEMAPHORE_POLL |
+   MI_SEMAPHORE_SAD_EQ_SDD;
+   *cs++ = 0;
+   *cs++ = lower_32_bits(vma->node.start);
+   *cs++ = upper_32_bits(vma->node.start);
+
+   if (*prev) {
+   u64 offset = (*prev)->batch->node.start;
+
+   *cs++ = MI_STORE_DWORD_IMM_GEN4;
+   *cs++ = lower_32_bits(offset);
+   *cs++ = upper_32_bits(offset);
+   *cs++ = 0;
+   }
+
+   *cs++ = MI_BATCH_BUFFER_END;
+   i915_gem_object_flush_map(obj);
+   i915_gem_object_unpin_map(obj);
+
+   rq = intel_context_create_request(ce);
+   if (IS_ERR(rq))
+   goto err_obj;
+
+   rq->batch = vma;
+   i915_request_get(rq);
+
+   i915_vma_lock(vma);
+   err = i915_request_await_object(rq, vma->obj, false);
+   if (!err)
+   err = i915_vma_move_to_active(vma, rq, 0);
+   if (!err)
+   err = rq->engine->emit_bb_start(rq,
+   vma->node.start,
+   PAGE_SIZE, 0);
+   i915_vma_unlock(vma);
+   i915_request_add(rq);
+   if (err)
+   goto err_rq;
+
+   i915_gem_object_put(obj);
+   intel_context_put(ce);
+
+   rq->client_link.next = &(*prev)->client_link;
+   *prev = rq;
+   return 0;
+
+err_rq:
+   i915_request_put(rq);
+err_obj:
+   i915_gem_object_put(obj);
+err_ce:
+   intel_context_put(ce);
+   return err;
+}
+
+static int live_preempt_gang(void *arg)
+{
+   struct intel_gt *gt = arg;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   if (!HAS_LOGICAL_RING_PREEMPTION(gt->i915))
+   return 0;
+
+   /*
+* Build as long a chain of preempters as we can, with each
+* request higher priority than the last. Once we give, we release
+* the last batch which then precolates down the chain, each releasing
+* the next oldest. The intent is to simply push as hard as we can
+* with the number of preemptions, trying to exceed narrow HW limits.
+* At a minimum, we insist that we can sort all the user high
+* priority levels into execution order.
+*/
+
+   for_each_engine(engine, gt, id) {
+   struct i915_request *rq = NULL;
+   struct igt_live_test t;
+   IGT_TIMEOUT(end_time);
+   int prio = 0;
+   int err = 0;
+   u32 *cs;
+
+   if (!intel_engine_has_preemption(engine))
+   continue;
+
+   if (igt_live_test_begin(, gt->i915, __func__, engine->name))
+   return -EIO;
+
+   do {
+   struct i915_sched_attr attr = {
+   .priority = I915_USER_PRIORITY(prio++),
+   };
+
+   err = create_gang(engine, );
+   if (err)
+   break;
+
+   engine->schedule(rq, );
+
+   if (prio <= I915_PRIORITY_MAX)
+   continue;
+
+   if (prio > (INT_MAX >> I915_USER_PRIORITY_SHIFT))
+   break;
+
+   if 

[Intel-gfx] [PATCH] drm/i915: Flush all user surfaces prior to first use

2019-11-12 Thread Chris Wilson
Since userspace has the ability to bypass the CPU cache from within its
unprivileged command stream, we have to flush the CPU cache to memory
in order to overwrite the previous contents on creation. We enforce this
at the boundary points (get/put pages) to ensure that before recycling
system pages we are always cache coherent.

v3: We now always clflush on acquisition and release of system pages,
and include a clflush counting selftest to make sure we do. This also
succinctly covers swap-in/swap-out.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Cc: Francisco Jerez 
Cc: Daniel Vetter 
---
Remember the difference in clflush behaviour between llc and !llc.
---
 drivers/gpu/drm/i915/gem/i915_gem_clflush.c   |   8 ++
 drivers/gpu/drm/i915/gem/i915_gem_clflush.h   |   6 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   7 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  22 +++-
 .../i915/gem/selftests/i915_gem_coherency.c   | 113 ++
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 6 files changed, 153 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index b9f504ba3b32..e2434e17ffc1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -16,11 +16,19 @@ struct clflush {
struct drm_i915_gem_object *obj;
 };
 
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+void st_clflush_inc(struct drm_i915_gem_object *obj)
+{
+   atomic_inc(_i915(obj->base.dev)->gem.clflushes);
+}
+#endif
+
 static void __do_clflush(struct drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
drm_clflush_sg(obj->mm.pages);
intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
+   st_clflush_inc(obj);
 }
 
 static int clflush_work(struct dma_fence_work *base)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h 
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
index e6c382973129..7434d878a553 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
@@ -17,4 +17,10 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 #define I915_CLFLUSH_FORCE BIT(0)
 #define I915_CLFLUSH_SYNC BIT(1)
 
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+void st_clflush_inc(struct drm_i915_gem_object *obj);
+#else
+static inline void st_clflush_inc(struct drm_i915_gem_object *obj) { }
+#endif
+
 #endif /* __I915_GEM_CLFLUSH_H__ */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index f402c2c415c2..8bcf9b65d661 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -5,9 +5,10 @@
  */
 
 #include "i915_drv.h"
+#include "i915_gem_clflush.h"
+#include "i915_gem_lmem.h"
 #include "i915_gem_object.h"
 #include "i915_scatterlist.h"
-#include "i915_gem_lmem.h"
 
 void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
 struct sg_table *pages,
@@ -25,8 +26,10 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object 
*obj,
/* Make the pages coherent with the GPU (flushing any swapin). */
if (obj->cache_dirty) {
obj->write_domain = 0;
-   if (i915_gem_object_has_struct_page(obj))
+   if (i915_gem_object_has_struct_page(obj)) {
drm_clflush_sg(pages);
+   st_clflush_inc(obj);
+   }
obj->cache_dirty = false;
}
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 4d69c3fc3439..9db53a4d1b2e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -10,6 +10,7 @@
 #include "gem/i915_gem_region.h"
 #include "i915_drv.h"
 #include "i915_gemfs.h"
+#include "i915_gem_clflush.h"
 #include "i915_gem_object.h"
 #include "i915_scatterlist.h"
 #include "i915_trace.h"
@@ -183,6 +184,15 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj, st);
 
+   /*
+* Since userspace has the ability to bypass the CPU cache from within
+* its unprivileged command stream, we have to flush the CPU cache to
+* memory in order to overwrite the previous contents on creation, so
+* that userspace cannot snoop on the old system pages just handed to
+* us.
+*/
+   obj->cache_dirty = true; /* For drm_clflush_sg() inside set_pages */
+
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
 
return 0;
@@ -285,10 +295,16 @@ __i915_gem_object_release_shmem(struct 
drm_i915_gem_object *obj,
if (obj->mm.madv == I915_MADV_DONTNEED)
obj->mm.dirty = false;
 
-   if (needs_clflush &&
-   (obj->read_domains & 

Re: [Intel-gfx] [PULL] gvt-fixes

2019-11-12 Thread Vivi, Rodrigo
pulled, thanks

> On Nov 11, 2019, at 10:18 PM, Zhenyu Wang  wrote:
> 
> 
> Hi,
> 
> Here's one GVT dmabuf reference drop fix from Pan Bian.
> 
> Thanks
> --
> The following changes since commit ee2c5ef8a9d640ee1617ec97b84fe2f634284e51:
> 
>  drm/i915/dp: Do not switch aux to TBT mode for non-TC ports (2019-11-04 
> 13:24:14 -0800)
> 
> are available in the Git repository at:
> 
>  https://github.com/intel/gvt-linux.git tags/gvt-fixes-2019-11-12
> 
> for you to fetch changes up to 41d931459b53e32c67a1f8838d1e6826a69ee745:
> 
>  drm/i915/gvt: fix dropping obj reference twice (2019-11-08 11:04:07 +0800)
> 
> 
> gvt-fixes-2019-11-12
> 
> - Fix dmabuf reference drop (Pan)
> 
> 
> Pan Bian (1):
>  drm/i915/gvt: fix dropping obj reference twice
> 
> drivers/gpu/drm/i915/gvt/dmabuf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

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

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Add support for integrated privacy screens

2019-11-12 Thread Rajat Jain
On Mon, Nov 4, 2019 at 11:41 AM Rajat Jain  wrote:
>
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use to control and check the status.
>
> Identifying the presence of privacy screen, and controlling it, is done
> via ACPI _DSM methods.
>
> Currently, this is done only for the Intel display ports. But in future,
> this can be done for any other ports if the hardware becomes available
> (e.g. external monitors supporting integrated privacy screens?).
>
> Signed-off-by: Rajat Jain 
> Change-Id: Ic9ff07fc4a50797d2d0dfb919f11aa0821a4b548


Hi Folks,

I posted a v2 taking care of the comments I received (also split it
into 3 patches now, and resused some ACPI code I found in i915
driver). . Wondering if any one got a chance to look at this?

Thanks,

Rajat

> ---
> v2: Formed by splitting the original patch into multiple patches.
> - All code has been moved into i915 now.
> - Privacy screen is a i915 property
> - Have a local state variable to store the prvacy screen. Don't read
>   it from hardware.
>
>  drivers/gpu/drm/i915/Makefile |  3 +-
>  drivers/gpu/drm/i915/display/intel_atomic.c   | 13 +++-
>  .../gpu/drm/i915/display/intel_connector.c| 35 ++
>  .../gpu/drm/i915/display/intel_connector.h|  1 +
>  .../drm/i915/display/intel_display_types.h|  4 ++
>  drivers/gpu/drm/i915/display/intel_dp.c   |  5 ++
>  .../drm/i915/display/intel_privacy_screen.c   | 70 +++
>  .../drm/i915/display/intel_privacy_screen.h   | 25 +++
>  include/uapi/drm/i915_drm.h   | 14 
>  9 files changed, 166 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 2587ea834f06..3589ebcf27bc 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -185,7 +185,8 @@ i915-y += \
> display/intel_tc.o
>  i915-$(CONFIG_ACPI) += \
> display/intel_acpi.o \
> -   display/intel_opregion.o
> +   display/intel_opregion.o \
> +   display/intel_privacy_screen.o
>  i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
> display/intel_fbdev.o
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c 
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index d3fb75bb9eb1..378772d3449c 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -37,6 +37,7 @@
>  #include "intel_atomic.h"
>  #include "intel_display_types.h"
>  #include "intel_hdcp.h"
> +#include "intel_privacy_screen.h"
>  #include "intel_sprite.h"
>
>  /**
> @@ -57,11 +58,14 @@ int intel_digital_connector_atomic_get_property(struct 
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> +   struct intel_connector *intel_connector = 
> to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property)
> *val = intel_conn_state->force_audio;
> else if (property == dev_priv->broadcast_rgb_property)
> *val = intel_conn_state->broadcast_rgb;
> +   else if (property == intel_connector->privacy_screen_property)
> +   *val = intel_conn_state->privacy_screen_status;
> else {
> DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
>  property->base.id, property->name);
> @@ -89,15 +93,18 @@ int intel_digital_connector_atomic_set_property(struct 
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> +   struct intel_connector *intel_connector = 
> to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property) {
> intel_conn_state->force_audio = val;
> return 0;
> -   }
> -
> -   if (property == dev_priv->broadcast_rgb_property) {
> +   } else if (property == dev_priv->broadcast_rgb_property) {
> intel_conn_state->broadcast_rgb = val;
> return 0;
> +   } else if (property == intel_connector->privacy_screen_property) {
> +   intel_privacy_screen_set_val(intel_connector, val);
> +   intel_conn_state->privacy_screen_status = val;
> +   return 0;
> }
>
> DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c 
> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flush all user surfaces prior to first use (rev4)

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Flush all user surfaces prior to first use (rev4)
URL   : https://patchwork.freedesktop.org/series/63871/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7322 -> Patchwork_15238


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15238 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15238, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_15238:

### IGT changes ###

 Possible regressions 

  * igt@gem_ctx_switch@rcs0:
- fi-icl-dsi: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-icl-dsi/igt@gem_ctx_swi...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-icl-dsi/igt@gem_ctx_swi...@rcs0.html

  * igt@i915_selftest@live_coherency:
- fi-byt-n2820:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-byt-n2820/igt@i915_selftest@live_coherency.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-byt-n2820/igt@i915_selftest@live_coherency.html
- fi-elk-e7500:   [PASS][5] -> [DMESG-FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-elk-e7500/igt@i915_selftest@live_coherency.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-elk-e7500/igt@i915_selftest@live_coherency.html
- fi-bwr-2160:[PASS][7] -> [DMESG-FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-bwr-2160/igt@i915_selftest@live_coherency.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-bwr-2160/igt@i915_selftest@live_coherency.html
- fi-bsw-nick:[PASS][9] -> [DMESG-FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-bsw-nick/igt@i915_selftest@live_coherency.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-bsw-nick/igt@i915_selftest@live_coherency.html
- fi-bxt-dsi: [PASS][11] -> [DMESG-FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-bxt-dsi/igt@i915_selftest@live_coherency.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-bxt-dsi/igt@i915_selftest@live_coherency.html
- fi-gdg-551: [PASS][13] -> [DMESG-FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-gdg-551/igt@i915_selftest@live_coherency.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-gdg-551/igt@i915_selftest@live_coherency.html
- fi-ilk-650: [PASS][15] -> [DMESG-FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-ilk-650/igt@i915_selftest@live_coherency.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-ilk-650/igt@i915_selftest@live_coherency.html
- fi-bsw-n3050:   [PASS][17] -> [DMESG-FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-bsw-n3050/igt@i915_selftest@live_coherency.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-bsw-n3050/igt@i915_selftest@live_coherency.html
- fi-glk-dsi: [PASS][19] -> [DMESG-FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-glk-dsi/igt@i915_selftest@live_coherency.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-glk-dsi/igt@i915_selftest@live_coherency.html
- fi-bsw-kefka:   [PASS][21] -> [DMESG-FAIL][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-bsw-kefka/igt@i915_selftest@live_coherency.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-bsw-kefka/igt@i915_selftest@live_coherency.html
- fi-blb-e6850:   [PASS][23] -> [DMESG-FAIL][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-blb-e6850/igt@i915_selftest@live_coherency.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-blb-e6850/igt@i915_selftest@live_coherency.html
- fi-apl-guc: [PASS][25] -> [DMESG-FAIL][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-apl-guc/igt@i915_selftest@live_coherency.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-apl-guc/igt@i915_selftest@live_coherency.html
- fi-pnv-d510:[PASS][27] -> [DMESG-FAIL][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7322/fi-pnv-d510/igt@i915_selftest@live_coherency.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15238/fi-pnv-d510/igt@i915_selftest@live_coherency.html
- fi-byt-j1900:   [PASS][29] -> 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flush context free work on cleanup (rev2)

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Flush context free work on cleanup (rev2)
URL   : https://patchwork.freedesktop.org/series/69339/
State : failure

== Summary ==

Applying: drm/i915: Flush context free work on cleanup
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/gem/i915_gem_context.c
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bios: use a flag for vbt hdmi level shift presence (rev4)

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915/bios: use a flag for vbt hdmi level shift presence (rev4)
URL   : https://patchwork.freedesktop.org/series/68998/
State : failure

== Summary ==

Applying: drm/i915/bios: use a flag for vbt hdmi level shift presence
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_bios.c
M   drivers/gpu/drm/i915/display/intel_ddi.c
M   drivers/gpu/drm/i915/i915_drv.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_drv.h
Auto-merging drivers/gpu/drm/i915/display/intel_ddi.c
Auto-merging drivers/gpu/drm/i915/display/intel_bios.c
No changes -- Patch already applied.

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Flush all user surfaces prior to first use

2019-11-12 Thread Francisco Jerez
Chris Wilson  writes:

> Quoting Francisco Jerez (2019-07-24 21:37:24)
>> Chris Wilson  writes:
>> 
>> > Since userspace has the ability to bypass the CPU cache from within its
>> > unprivileged command stream, we have to flush the CPU cache to memory
>> > in order to overwrite the previous contents on creation.
>> >
>> > Signed-off-by: Chris Wilson 
>> > Cc: Joonas Lahtinen 
>> > Cc: stablevger.kernel.org
>> > ---
>> >  drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 26 ++-
>> >  1 file changed, 7 insertions(+), 19 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
>> > b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> > index d2a1158868e7..f752b326d399 100644
>> > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> > @@ -459,7 +459,6 @@ i915_gem_object_create_shmem(struct drm_i915_private 
>> > *i915, u64 size)
>> >  {
>> >   struct drm_i915_gem_object *obj;
>> >   struct address_space *mapping;
>> > - unsigned int cache_level;
>> >   gfp_t mask;
>> >   int ret;
>> >  
>> > @@ -498,24 +497,13 @@ i915_gem_object_create_shmem(struct drm_i915_private 
>> > *i915, u64 size)
>> >   obj->write_domain = I915_GEM_DOMAIN_CPU;
>> >   obj->read_domains = I915_GEM_DOMAIN_CPU;
>> >  
>> > - if (HAS_LLC(i915))
>> > - /* On some devices, we can have the GPU use the LLC (the CPU
>> > -  * cache) for about a 10% performance improvement
>> > -  * compared to uncached.  Graphics requests other than
>> > -  * display scanout are coherent with the CPU in
>> > -  * accessing this cache.  This means in this mode we
>> > -  * don't need to clflush on the CPU side, and on the
>> > -  * GPU side we only need to flush internal caches to
>> > -  * get data visible to the CPU.
>> > -  *
>> > -  * However, we maintain the display planes as UC, and so
>> > -  * need to rebind when first used as such.
>> > -  */
>> > - cache_level = I915_CACHE_LLC;
>> > - else
>> > - cache_level = I915_CACHE_NONE;
>> > -
>> > - i915_gem_object_set_cache_coherency(obj, cache_level);
>> > + /*
>> > +  * Note that userspace has control over cache-bypass
>> > +  * via its command stream, so even on LLC architectures
>> > +  * we have to flush out the CPU cache to memory to
>> > +  * clear previous contents.
>> > +  */
>> > + i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
>> >  
>> 
>> I'm not sure if you've seen my comments about this in an internal thread
>> you were CC'ed to: I don't think this patch will have the intended
>> effect.  The various clflushes this could trigger before the first use
>> of the buffer are conditional on "obj->cache_dirty &
>> ~obj->cache_coherent", which will always be false on LLC platforms
>> AFAICT, because on those platforms i915_gem_object_set_cache_coherency()
>> will always set bit 0 of obj->cache_coherent.
>
> You only need to flush the stale written-to cachelines, so that the page
> content is correct on reuse of the foreign struct page. After that point,
> the CPU cache is managed by the client.

Point was that the code above wouldn't have necessarily led to *any*
flushing on Gen11+ platforms, not even of stale written-to cachelines,
because the various clflushes this could have triggered before the first
use of the buffer were conditional on "obj->cache_dirty &
~obj->cache_coherent", which would still have been false on LLC
platforms.

Anyway you may have fixed that in the next revision of this patch you
sent today by doing things in a completely different way.  But you
didn't answer my question asking why you are doing this on all
platforms.  Cache bypass isn't available on ICL nor earlier platforms,
is it?  And it's been defeatured on TGL:

https://www.spinics.net/lists/intel-gfx/msg219552.html

> -Chris




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] drm/i915: Fix detection for a CMP-V PCH

2019-11-12 Thread Souza, Jose
On Tue, 2019-11-12 at 12:46 +0200, Imre Deak wrote:
> According to internal documents I found for CMP PCHs the PCI ID
> 0xA3C1
> belongs to a CMP-V chipset. Based on the same docs the programming of
> the PCH is compatible with that of KBP. Fix up my previous wrong
> assumption accordingly using the SPT programming which in turn is the
> basis for KBP.
> 
> The original bug reporter verified that this is the correct PCH
> identification (the only way we'll program valid DDC pin-pair values
> to
> the GMBUS register) and the Windows team uses the same identification
> (that is using the KBP programming model for this PCH).
> 
> I filed the necessary Bspec update requests (BSpec/33734).


Reviewed-by: José Roberto de Souza 

> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
> Fixes: 37c92dc303dd ("drm/i915: Add new CNL PCH ID seen on a CML
> platform")
> Reported-and-tested-by: Cyrus 
> Cc: Cyrus 
> Cc: Timo Aaltonen 
> Cc: José Roberto de Souza 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_pch.c | 6 +-
>  drivers/gpu/drm/i915/intel_pch.h | 2 +-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c
> index fd22355b9a96..43b68b5fc562 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -62,7 +62,6 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id)
>   /* KBP is SPT compatible */
>   return PCH_SPT;
>   case INTEL_PCH_CNP_DEVICE_ID_TYPE:
> - case INTEL_PCH_CNP2_DEVICE_ID_TYPE:
>   DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
>   WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> !IS_COFFEELAKE(dev_priv));
>   return PCH_CNP;
> @@ -76,6 +75,11 @@ intel_pch_type(const struct drm_i915_private
> *dev_priv, unsigned short id)
>   WARN_ON(!IS_COFFEELAKE(dev_priv));
>   /* CometPoint is CNP Compatible */
>   return PCH_CNP;
> + case INTEL_PCH_CMP_V_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Comet Lake V PCH (CMP-V)\n");
> + WARN_ON(!IS_COFFEELAKE(dev_priv));
> + /* Comet Lake V PCH is based on KBP, which is SPT
> compatible */
> + return PCH_SPT;
>   case INTEL_PCH_ICP_DEVICE_ID_TYPE:
>   DRM_DEBUG_KMS("Found Ice Lake PCH\n");
>   WARN_ON(!IS_ICELAKE(dev_priv));
> diff --git a/drivers/gpu/drm/i915/intel_pch.h
> b/drivers/gpu/drm/i915/intel_pch.h
> index 52d145dcdb15..3053d1ce398b 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -40,10 +40,10 @@ enum intel_pch {
>  #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE  0x9D00
>  #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
>  #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> -#define INTEL_PCH_CNP2_DEVICE_ID_TYPE0xA380
>  #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE  0x9D80
>  #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
>  #define INTEL_PCH_CMP2_DEVICE_ID_TYPE0x0680
> +#define INTEL_PCH_CMP_V_DEVICE_ID_TYPE   0xA380
>  #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
>  #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
>  #define INTEL_PCH_TGP_DEVICE_ID_TYPE 0xA080
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Explicitly cleanup initial_plane_config

2019-11-12 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Explicitly cleanup 
initial_plane_config
URL   : https://patchwork.freedesktop.org/series/69355/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7320 -> Patchwork_15235


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/index.html

Known issues


  Here are the changes found in Patchwork_15235 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0:
- fi-bsw-n3050:   [PASS][1] -> [DMESG-WARN][2] ([fdo#112120])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7320/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#110343]: https://bugs.freedesktop.org/show_bug.cgi?id=110343
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [fdo#112120]: https://bugs.freedesktop.org/show_bug.cgi?id=112120


Participating hosts (52 -> 41)
--

  Missing(11): fi-ilk-m540 fi-cml-s fi-hsw-4200u fi-skl-6770hq fi-skl-guc 
fi-byt-squawks fi-bsw-cyan fi-gdg-551 fi-bdw-samus fi-byt-clapper fi-skl-6700k2 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7320 -> Patchwork_15235

  CI-20190529: 20190529
  CI_DRM_7320: 5ad80c1d1c967e3f0c9233fd6a70e7443b43d497 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5273: 602003c3d751c72fc309a0e64d4193f6da720f6b @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15235: dbbe43622a279c948ba84af4b32517fe7d2eb2af @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

dbbe43622a27 drm/i915/display: Be explicit in handling the preallocated vma
cb6d9ec76658 drm/i915: Explicitly cleanup initial_plane_config

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15235/index.html
___
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/psr: Add bits per pixel limitation

2019-11-12 Thread Souza, Jose
On Tue, 2019-11-12 at 09:16 -0800, Matt Roper wrote:
> On Tue, Nov 05, 2019 at 05:45:00PM -0800, José Roberto de Souza
> wrote:
> > PSR2 HW only support a limited number of bits per pixel, if mode
> > has
> > more than supported PSR2 should not be enabled.
> > 
> > BSpec: 50422
> > BSpec: 7713
> > Cc: Gwan-gyeong Mun 
> > Signed-off-by: José Roberto de Souza 
> > ---
> >  drivers/gpu/drm/i915/display/intel_psr.c | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index c1d133362b76..0d84ea28bc6f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -608,7 +608,7 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> > int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
> > -   int psr_max_h = 0, psr_max_v = 0;
> > +   int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;
> >  
> > if (!dev_priv->psr.sink_psr2_support)
> > return false;
> > @@ -632,12 +632,15 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > if (INTEL_GEN(dev_priv) >= 12) {
> > psr_max_h = 5120;
> > psr_max_v = 3200;
> > +   max_bpp = 30;
> > } else if (INTEL_GEN(dev_priv) >= 10 ||
> > IS_GEMINILAKE(dev_priv)) {
> > psr_max_h = 4096;
> > psr_max_v = 2304;
> > +   max_bpp = 24;
> > } else if (IS_GEN(dev_priv, 9)) {
> > psr_max_h = 3640;
> > psr_max_v = 2304;
> > +   max_bpp = 24;
> > }
> >  
> > if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
> > @@ -647,6 +650,12 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >  
> > +   if (crtc_state->pipe_bpp > max_bpp) {
> > +   DRM_DEBUG_KMS("PSR2 not enabled, pipe bpp %d > max
> > supported %d\n",
> > + crtc_state->pipe_bpp, max_bpp);
> > +   return false;
> > +   }
> 
> The wording of the bspec is "PSR2 is limited to 30bpp 10:10:10" and
> "PSR2 is limited to 24bpp 8:8:8" --- that wording makes it sound like
> you need to use that one specific mode rather than it being an upper
> limit?  I.e., do we need an == test here rather than >?

It works with lower than the limit:

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb4/igt@kms_psr2...@frontbuffer.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7309/shard-iclb2/igt@kms_psr@psr2_basic.html

But I agree with you, BSpec should have "limited up to Xbpp", going toopen a 
issue. 

> 
> 
> Matt
> 
> > +
> > /*
> >  * HW sends SU blocks of size four scan lines, which means the
> > starting
> >  * X coordinate and Y granularity requirements will always be
> > met. We
> > -- 
> > 2.24.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] i915: Mark up a few more tests that only target GGTT

2019-11-12 Thread Antonio Argenziano



On 12/11/19 10:21, Chris Wilson wrote:

Quoting Antonio Argenziano (2019-11-12 18:17:41)



On 12/11/19 07:47, Chris Wilson wrote:

If a test is only targeting the GGTT API and its corner cases, it can
only run if we have a mappable aperture.

Signed-off-by: Chris Wilson 
Cc: Antonio Argenziano 
---
   lib/i915/gem_mman.c | 19 +++
   lib/i915/gem_mman.h |  3 +++
   tests/i915/gem_gtt_cpu_tlb.c|  1 +
   tests/i915/gem_gtt_hog.c|  1 +
   tests/i915/gem_gtt_speed.c  |  2 ++
   tests/i915/gem_mmap_gtt.c   |  5 +
   tests/i915/gem_tiled_swapping.c |  1 +
   7 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 3cf9a6bbd..76d0be82e 100644
--- a/lib/i915/gem_mman.c
+++ b/lib/i915/gem_mman.c
@@ -252,3 +252,22 @@ void *gem_mmap__cpu(int fd, uint32_t handle, uint64_t 
offset, uint64_t size, uns
   igt_assert(ptr);
   return ptr;
   }
+
+bool gem_has_ggtt(int i915)


nit: I would put mapping or map or something in the name to make it
clear that the mapping is not accessible but, your call :).


I could go with has_ggtt_aperture()? Or has_mappable_ggtt()?
Both have their merits. Leaning towards has_mappable_ggtt.


+1 has_mappable_ggtt.


-Chris


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

Re: [Intel-gfx] [PATCH i-g-t] i915: Mark up a few more tests that only target GGTT

2019-11-12 Thread Chris Wilson
Quoting Antonio Argenziano (2019-11-12 18:17:41)
> 
> 
> On 12/11/19 07:47, Chris Wilson wrote:
> > If a test is only targeting the GGTT API and its corner cases, it can
> > only run if we have a mappable aperture.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Antonio Argenziano 
> > ---
> >   lib/i915/gem_mman.c | 19 +++
> >   lib/i915/gem_mman.h |  3 +++
> >   tests/i915/gem_gtt_cpu_tlb.c|  1 +
> >   tests/i915/gem_gtt_hog.c|  1 +
> >   tests/i915/gem_gtt_speed.c  |  2 ++
> >   tests/i915/gem_mmap_gtt.c   |  5 +
> >   tests/i915/gem_tiled_swapping.c |  1 +
> >   7 files changed, 28 insertions(+), 4 deletions(-)
> > 
> > diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> > index 3cf9a6bbd..76d0be82e 100644
> > --- a/lib/i915/gem_mman.c
> > +++ b/lib/i915/gem_mman.c
> > @@ -252,3 +252,22 @@ void *gem_mmap__cpu(int fd, uint32_t handle, uint64_t 
> > offset, uint64_t size, uns
> >   igt_assert(ptr);
> >   return ptr;
> >   }
> > +
> > +bool gem_has_ggtt(int i915)
> 
> nit: I would put mapping or map or something in the name to make it 
> clear that the mapping is not accessible but, your call :).

I could go with has_ggtt_aperture()? Or has_mappable_ggtt()?
Both have their merits. Leaning towards has_mappable_ggtt.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] i915: Mark up a few more tests that only target GGTT

2019-11-12 Thread Antonio Argenziano



On 12/11/19 07:47, Chris Wilson wrote:

If a test is only targeting the GGTT API and its corner cases, it can
only run if we have a mappable aperture.

Signed-off-by: Chris Wilson 
Cc: Antonio Argenziano 
---
  lib/i915/gem_mman.c | 19 +++
  lib/i915/gem_mman.h |  3 +++
  tests/i915/gem_gtt_cpu_tlb.c|  1 +
  tests/i915/gem_gtt_hog.c|  1 +
  tests/i915/gem_gtt_speed.c  |  2 ++
  tests/i915/gem_mmap_gtt.c   |  5 +
  tests/i915/gem_tiled_swapping.c |  1 +
  7 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 3cf9a6bbd..76d0be82e 100644
--- a/lib/i915/gem_mman.c
+++ b/lib/i915/gem_mman.c
@@ -252,3 +252,22 @@ void *gem_mmap__cpu(int fd, uint32_t handle, uint64_t 
offset, uint64_t size, uns
igt_assert(ptr);
return ptr;
  }
+
+bool gem_has_ggtt(int i915)


nit: I would put mapping or map or something in the name to make it 
clear that the mapping is not accessible but, your call :).


The patch looks good to me but IGT is quite different than the last time 
I played around with it so:

Acked-by: Antonio Argenziano 


+{
+   struct drm_i915_gem_mmap_gtt arg = {};
+   int err;
+
+   err = 0;
+   if (ioctl(i915, DRM_IOCTL_I915_GEM_MMAP_GTT, ))
+   err = errno;
+   errno = 0;
+
+   return errno != ENODEV;
+}
+
+void gem_require_ggtt(int i915)
+{
+   igt_require_f(gem_has_ggtt(i915),
+ "HW & kernel support for indirect detiling aperture\n");
+}
diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
index f7242ed77..67891c8de 100644
--- a/lib/i915/gem_mman.h
+++ b/lib/i915/gem_mman.h
@@ -35,6 +35,9 @@ void *gem_mmap__wc(int fd, uint32_t handle, uint64_t offset, 
uint64_t size, unsi
  #define I915_GEM_DOMAIN_WC 0x80
  #endif
  
+bool gem_has_ggtt(int i915);

+void gem_require_ggtt(int i915);
+
  void *__gem_mmap__gtt(int fd, uint32_t handle, uint64_t size, unsigned prot);
  void *__gem_mmap__cpu(int fd, uint32_t handle, uint64_t offset, uint64_t 
size, unsigned prot);
  void *__gem_mmap__wc(int fd, uint32_t handle, uint64_t offset, uint64_t size, 
unsigned prot);
diff --git a/tests/i915/gem_gtt_cpu_tlb.c b/tests/i915/gem_gtt_cpu_tlb.c
index cf3c543df..a4cbb1034 100644
--- a/tests/i915/gem_gtt_cpu_tlb.c
+++ b/tests/i915/gem_gtt_cpu_tlb.c
@@ -79,6 +79,7 @@ igt_simple_main
igt_skip_on_simulation();
  
  	fd = drm_open_driver(DRIVER_INTEL);

+   gem_require_ggtt(fd);
  
  	handle = gem_create(fd, OBJ_SIZE);
  
diff --git a/tests/i915/gem_gtt_hog.c b/tests/i915/gem_gtt_hog.c

index ca730649c..7a6273936 100644
--- a/tests/i915/gem_gtt_hog.c
+++ b/tests/i915/gem_gtt_hog.c
@@ -161,6 +161,7 @@ igt_simple_main
/* check for an intel gpu before goint nuts. */
int fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
+   gem_require_ggtt(fd);
close(fd);
  
  	igt_skip_on_simulation();

diff --git a/tests/i915/gem_gtt_speed.c b/tests/i915/gem_gtt_speed.c
index dfa7216cc..0cdd51dc3 100644
--- a/tests/i915/gem_gtt_speed.c
+++ b/tests/i915/gem_gtt_speed.c
@@ -124,7 +124,9 @@ igt_simple_main_args("s:", NULL, help_str, opt_handler, 
NULL)
  
  	buf = malloc(size);

memset(buf, 0, size);
+
fd = drm_open_driver(DRIVER_INTEL);
+   gem_require_ggtt(fd);
  
  	handle = gem_create(fd, size);

igt_assert(handle);
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index ac25f13e2..d31c73ed4 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -1020,8 +1020,6 @@ igt_main
OBJECT_SIZE = 1 * 1024 * 1024;
  
  	igt_fixture {

-   struct drm_i915_gem_mmap_gtt arg = {};
-
fd = drm_open_driver(DRIVER_INTEL);
  
  		/*

@@ -1029,8 +1027,7 @@ igt_main
 * detiling access from untrusted userspace to the objects,
 * the kernel does an early rejection of the mmap_gtt ioctl.
 */
-   igt_require_f(mmap_ioctl(fd, ) != -ENODEV,
- "HW & kernel support for indirect detiling 
aperture\n");
+   gem_require_ggtt(fd);
}
  
  	igt_subtest("bad-object") {

diff --git a/tests/i915/gem_tiled_swapping.c b/tests/i915/gem_tiled_swapping.c
index 1b70c1e51..3a95c9469 100644
--- a/tests/i915/gem_tiled_swapping.c
+++ b/tests/i915/gem_tiled_swapping.c
@@ -175,6 +175,7 @@ igt_main
current_tiling_mode = I915_TILING_X;
  
  		fd = drm_open_driver(DRIVER_INTEL);

+   gem_require_ggtt(fd);
  
  		intel_purge_vm_caches(fd);

check_memory_layout(fd);


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

Re: [Intel-gfx] [PATCH 26/27] drm/i915/gt: Refactor mocs loops into single control macro

2019-11-12 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-12 17:02:18)
> Chris Wilson  writes:
> > +static u32 mocs_register(const struct intel_engine_cs *engine)
> > +{
> > + static const u32 offset[] = {
> > + [RCS0]  = 0x0c800,
> > + [VCS0]  = 0x0c900,
> > + [VCS1]  = 0x0ca00,
> > + [VECS0] = 0x0cb00,
> > + [BCS0]  = 0x0cc00,
> > + [VCS2]  = 0x1,

A bit of a quandary as

@@ -361,12 +361,12 @@ static void __init_mocs_table(struct intel_uncore *uncore,
 static u32 mocs_register(const struct intel_engine_cs *engine)
 {
static const u32 offset[] = {
-   [RCS0]  = 0x0c800,
-   [VCS0]  = 0x0c900,
-   [VCS1]  = 0x0ca00,
-   [VECS0] = 0x0cb00,
-   [BCS0]  = 0x0cc00,
-   [VCS2]  = 0x1,
+   [RCS0]  = i915_mmio_reg_offset(GEN9_GFX_MOCS(0)),
+   [VCS0]  = i915_mmio_reg_offset(GEN9_MFX0_MOCS(0)),
+   [VCS1]  = i915_mmio_reg_offset(GEN9_BLT_MOCS(0)),
+   [VECS0] = i915_mmio_reg_offset(GEN9_VEBOX_MOCS(0)),
+   [BCS0]  = i915_mmio_reg_offset(GEN9_MFX1_MOCS(0)),
+   [VCS2]  = i915_mmio_reg_offset(GEN11_MFX2_MOCS(0)),
};

GEM_BUG_ON(engine->id >= ARRAY_SIZE(offset));

does not compile as they do not evaluate to a constant.

The alternative is to have the raw offsets for the indexed macros to
build off.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] i915/gem_exec_scheduler: Exercise priority inversion from resource contention

2019-11-12 Thread Daniel Vetter
On Fri, Nov 8, 2019 at 10:22 PM Chris Wilson  wrote:
>
> Quoting Daniel Vetter (2019-11-08 21:13:13)
> > On Fri, Nov 8, 2019 at 9:49 PM Chris Wilson  
> > wrote:
> > >
> > > One of the hardest priority inversion tasks to both handle and to
> > > simulate in testing is inversion due to resource contention. The
> > > challenge is that a high priority context should never be blocked by a
> > > low priority context, even if both are starving for resources --
> > > ideally, at least for some RT OSes, the higher priority context has
> > > first pick of the meagre resources so that it can be executed with
> > > minimum latency.
> > >
> > > userfaultfd allows us to handle a page fault in userspace, and so
> > > arbitrary impose a delay on the fault handler, creating a situation
> > > where a low priority context is blocked waiting for the fault. This
> > > blocked context should not prevent a high priority context from being
> > > executed. While the userfault tries to emulate a slow fault (e.g. from a
> > > failing swap device), it is unfortunately limited to a single object
> > > type: the userptr. Hopefully, we will find other ways to impose other
> > > starvation conditions on global resources.
> > >
> > > Signed-off-by: Chris Wilson 
> > > Cc: Joonas Lahtinen 
> > > Cc: Tvrtko Ursulin 
> >
> > So rt-ww_mutexes?
> >
> > I don't think we want/should do that on the first round of rolling out
> > ww_mutex in i915.
>
> It works today. And will continue working across any conversion.

Isn't that just an artifact of how we retry userptr page-in? I think
if we'd do this check with other objects, then it'll fall apart ...
-Daniel
-- 
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 v6 09/10] drm/framebuffer/tgl: Format modifier for Intel Gen 12 render compression with Clear Color

2019-11-12 Thread Chery, Nanley G
> From: Sripada, Radhakrishna
> Sent: Friday, November 01, 2019 12:00 AM
> To: Chery, Nanley G; intel-gfx@lists.freedesktop.org
> Cc: Pandiyan, Dhinakaran; Syrjala, Ville; Sharma, Shashank; Antognolli, 
> Rafael; Ville Syrjala; Ekstrand, Jason
> Subject: RE: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel 
> Gen 12 render compression with Clear Color
> 
> Hi Nanley,
> 
> > -Original Message-
> > From: Chery, Nanley G
> > Sent: Tuesday, October 29, 2019 5:05 PM
> > To: Sripada, Radhakrishna ; intel-
> > g...@lists.freedesktop.org
> > Cc: Pandiyan, Dhinakaran ; Syrjala, Ville
> > ; Sharma, Shashank
> > ; Antognolli, Rafael
> > ; Ville Syrjala 
> > ;
> > Ekstrand, Jason 
> > Subject: RE: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for Intel
> > Gen 12 render compression with Clear Color
> >
> > +Jason
> >
> > Maybe Jason and/or others have some thoughts on the following? Given the
> > detailed description of the clear color struct, it seems like we'll have to 
> > define
> > a new modifier if the struct fields change in a future generation.
> >
> > On negative is that we might have to make new modifiers that provide no
> > additional benefit (assuming the new/changed fields are unused). On
> > positive is that it's probably a good thing that we mentioned the Raw clear
> > color fields because I think 3D uses it during rendering operations and 
> > we'll
> > be sharing from 3D-to-3D. Maybe we should specify how the channels
> > should be formatted?
> >
> > I haven't thought through how fields like Color Discard Enable affect buffer
> > sharing...
> >
> > Another comment: I noticed that none of the Y+CCS modifiers explicitly state
> > that the CCS must be in the same BO as the Y-tiled main surface. We should
> > at least fix that for newly defined modifiers right?
> I have not tried to use separate bo for the different surfaces. That is 
> probably worth a try.
> I wonder if we are using that for any of the modifiers to have an explicit 
> comment?

I didn't think it was possible to use a separate BO for the aux data. AFAICT
the location of the aux data is specified as an offset from the main surface
using the PLANE_AUX_DIST register.

-Nanley

> 
> Thanks,
> RK
> >
> > -Nanley
> >
> > > 
> > > From: Sripada, Radhakrishna
> > > Sent: Monday, October 28, 2019 1:40 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Pandiyan, Dhinakaran; Syrjala, Ville; Sharma, Shashank;
> > > Antognolli, Rafael; Chery, Nanley G; Sripada, Radhakrishna; Ville
> > > Syrjala; Kondapally, Kalyan
> > > Subject: [PATCH v6 09/10] drm/framebuffer/tgl: Format modifier for
> > > Intel Gen 12 render compression with Clear Color
> > >
> > > Gen12 display can decompress surfaces compressed by render engine with
> > > Clear Color, add a new modifier as the driver needs to know the
> > > surface was compressed by render engine.
> > >
> > > V2: Description changes as suggested by Rafael.
> > > V3: Mention the Clear Color size of 64 bits in the comments(DK)
> > > v4: Fix trailing whitespaces
> > > v5: Explain Clear Color in the documentation.
> > > v6: Documentation Nitpicks(Nanley)
> > >
> > > Cc: Ville Syrjala 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Kalyan Kondapally 
> > > Cc: Rafael Antognolli 
> > > Cc: Nanley Chery 
> > > Signed-off-by: Radhakrishna Sripada 
> > > ---
> > >  include/uapi/drm/drm_fourcc.h | 19 +++
> > >  1 file changed, 19 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > b/include/uapi/drm/drm_fourcc.h index 1aa6d468c048..4aa7f3f9712a
> > > 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -434,6 +434,25 @@ extern "C" {
> > >   */
> > >  #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
> > fourcc_mod_code(INTEL,
> > > 7)
> > >
> > > +/*
> > > + * Intel Color Control Surface with Clear Color (CCS) for Gen-12
> > > +render
> > > + * compression.
> > > + *
> > > + * The main surface is Y-tiled and is at plane index 0 whereas CCS is
> > > +linear
> > > + * and at index 1. The clear color is stored at index 2, and the
> > > +pitch should
> > > + * be ignored. The clear color structure is 256 bits. The first 128
> > > +bits
> > > + * represents Raw Clear Color Red, Green, Blue and Alpha color each
> > > +represented
> > > + * by 32 bits. The raw clear color is consumed by the 3d engine and
> > > +generates
> > > + * the converted clear color of size 64 bits. The first 32 bits store
> > > +the Lower
> > > + * Converted Clear Color value and the next 32 bits store the Higher
> > > +Converted
> > > + * Clear Color value when applicable. The Converted Clear Color
> > > +values are
> > > + * consumed by the DE. The last 64 bits are used to store Color
> > > +Discard Enable
> > > + * and Depth Clear Value Valid which are ignored by the DE. A CCS
> > > +cache line
> > > + * corresponds to an area of 4x1 tiles in the main surface. The main
> > > +surface
> > > + * pitch is 

Re: [Intel-gfx] [PATCH 2/5] drm/i915/psr: Refactor psr short pulse handler

2019-11-12 Thread Matt Roper
On Tue, Nov 05, 2019 at 05:45:01PM -0800, José Roberto de Souza wrote:
> eDP spec states that when sink enconters a problem that prevents it
> to keep PSR running it should set PSR status to internal error and
> set the reason why it happen to PSR_ERROR_STATUS but it is not how it
> was implemented.
> But also I don't want to change this behavior, who knows if there is
> a panel out there that only set the PSR_ERROR_STATUS.
> 
> So here refactoring the code a bit to make more easy to read what was
> state above as more checks will be added to this function.
> 
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 51 ++--
>  1 file changed, 31 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 0d84ea28bc6f..f38da1b9b323 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1386,11 +1386,30 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
>   mutex_init(_priv->psr.lock);
>  }
>  
> +static bool psr_get_status_and_error_status(struct intel_dp *intel_dp,
> + u8 *status, u8 *error_status)

This should probably return an integer rather than a bool to match the
kernel coding style guidelines:

"""
If the name of a function is an action or an imperative command,
the function should return an error-code integer.  If the name
is a predicate, the function should return a "succeeded"
boolean.
"""


Matt

> +{
> + struct drm_dp_aux *aux = _dp->aux;
> + int r;
> +
> + r = drm_dp_dpcd_readb(aux, DP_PSR_STATUS, status);
> + if (r != 1)
> + return false;
> +
> + r = drm_dp_dpcd_readb(aux, DP_PSR_ERROR_STATUS, error_status);
> + if (r != 1)
> + return false;
> +
> + *status = *status & DP_PSR_SINK_STATE_MASK;
> +
> + return true;
> +}
> +
>  void intel_psr_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   struct i915_psr *psr = _priv->psr;
> - u8 val;
> + u8 status, error_status;
>   const u8 errors = DP_PSR_RFB_STORAGE_ERROR |
> DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
> DP_PSR_LINK_CRC_ERROR;
> @@ -1403,38 +1422,30 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
>   if (!psr->enabled || psr->dp != intel_dp)
>   goto exit;
>  
> - if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, ) != 1) {
> - DRM_ERROR("PSR_STATUS dpcd read failed\n");
> + if (!psr_get_status_and_error_status(intel_dp, , _status)) 
> {
> + DRM_ERROR("Error reading PSR status or error status\n");
>   goto exit;
>   }
>  
> - if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) {
> - DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
> + if (status == DP_PSR_SINK_INTERNAL_ERROR || (error_status & errors)) {
>   intel_psr_disable_locked(intel_dp);
>   psr->sink_not_reliable = true;
>   }
>  
> - if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_ERROR_STATUS, ) != 1) {
> - DRM_ERROR("PSR_ERROR_STATUS dpcd read failed\n");
> - goto exit;
> - }
> -
> - if (val & DP_PSR_RFB_STORAGE_ERROR)
> + if (status == DP_PSR_SINK_INTERNAL_ERROR && !error_status)
> + DRM_DEBUG_KMS("PSR sink internal error, disabling PSR\n");
> + if (error_status & DP_PSR_RFB_STORAGE_ERROR)
>   DRM_DEBUG_KMS("PSR RFB storage error, disabling PSR\n");
> - if (val & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
> + if (error_status & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
>   DRM_DEBUG_KMS("PSR VSC SDP uncorrectable error, disabling 
> PSR\n");
> - if (val & DP_PSR_LINK_CRC_ERROR)
> + if (error_status & DP_PSR_LINK_CRC_ERROR)
>   DRM_DEBUG_KMS("PSR Link CRC error, disabling PSR\n");
>  
> - if (val & ~errors)
> + if (error_status & ~errors)
>   DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
> -   val & ~errors);
> - if (val & errors) {
> - intel_psr_disable_locked(intel_dp);
> - psr->sink_not_reliable = true;
> - }
> +   error_status & ~errors);
>   /* clear status register */
> - drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, val);
> + drm_dp_dpcd_writeb(_dp->aux, DP_PSR_ERROR_STATUS, error_status);
>  exit:
>   mutex_unlock(>lock);
>  }
> -- 
> 2.24.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795

Re: [Intel-gfx] [PATCH 1/5] drm/i915/psr: Add bits per pixel limitation

2019-11-12 Thread Matt Roper
On Tue, Nov 05, 2019 at 05:45:00PM -0800, José Roberto de Souza wrote:
> PSR2 HW only support a limited number of bits per pixel, if mode has
> more than supported PSR2 should not be enabled.
> 
> BSpec: 50422
> BSpec: 7713
> Cc: Gwan-gyeong Mun 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index c1d133362b76..0d84ea28bc6f 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -608,7 +608,7 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
> - int psr_max_h = 0, psr_max_v = 0;
> + int psr_max_h = 0, psr_max_v = 0, max_bpp = 0;
>  
>   if (!dev_priv->psr.sink_psr2_support)
>   return false;
> @@ -632,12 +632,15 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   if (INTEL_GEN(dev_priv) >= 12) {
>   psr_max_h = 5120;
>   psr_max_v = 3200;
> + max_bpp = 30;
>   } else if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
>   psr_max_h = 4096;
>   psr_max_v = 2304;
> + max_bpp = 24;
>   } else if (IS_GEN(dev_priv, 9)) {
>   psr_max_h = 3640;
>   psr_max_v = 2304;
> + max_bpp = 24;
>   }
>  
>   if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
> @@ -647,6 +650,12 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   return false;
>   }
>  
> + if (crtc_state->pipe_bpp > max_bpp) {
> + DRM_DEBUG_KMS("PSR2 not enabled, pipe bpp %d > max supported 
> %d\n",
> +   crtc_state->pipe_bpp, max_bpp);
> + return false;
> + }

The wording of the bspec is "PSR2 is limited to 30bpp 10:10:10" and
"PSR2 is limited to 24bpp 8:8:8" --- that wording makes it sound like
you need to use that one specific mode rather than it being an upper
limit?  I.e., do we need an == test here rather than >?


Matt

> +
>   /*
>* HW sends SU blocks of size four scan lines, which means the starting
>* X coordinate and Y granularity requirements will always be met. We
> -- 
> 2.24.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove leftover gem.pm_notifier member

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove leftover gem.pm_notifier member
URL   : https://patchwork.freedesktop.org/series/69348/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7312_full -> Patchwork_15231_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_15231_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb1/igt@gem_ctx_persiste...@vcs1-queued.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-iclb5/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_exec_schedule@out-order-bsd2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +9 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb1/igt@gem_exec_sched...@out-order-bsd2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-iclb5/igt@gem_exec_sched...@out-order-bsd2.html

  * igt@gem_exec_schedule@preempt-self-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +1 similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb8/igt@gem_exec_sched...@preempt-self-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-iclb4/igt@gem_exec_sched...@preempt-self-bsd.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111832]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb2/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-tglb1/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy:
- shard-hsw:  [PASS][9] -> [DMESG-WARN][10] ([fdo#111870])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-hsw6/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-hsw4/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html

  * igt@gem_workarounds@suspend-resume:
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([fdo#111832] / 
[fdo#111850]) +1 similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb1/igt@gem_workarou...@suspend-resume.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-tglb3/igt@gem_workarou...@suspend-resume.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#111830 ])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb3/igt@i915_pm...@dc6-psr.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-iclb2/igt@i915_pm...@dc6-psr.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([fdo#110741])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#105363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-skl7/igt@kms_f...@flip-vs-expired-vblank.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-apl:  [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-apl7/igt@kms_f...@flip-vs-suspend-interruptible.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-apl1/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
- shard-snb:  [PASS][21] -> [SKIP][22] ([fdo#109271]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-snb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-pwrite.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-snb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-tglb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +1 similar 
issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15231/shard-tglb9/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html

  * 

Re: [Intel-gfx] [PATCH 26/27] drm/i915/gt: Refactor mocs loops into single control macro

2019-11-12 Thread Mika Kuoppala
Chris Wilson  writes:

> We repeatedly (and more so in future) use the same looping construct
> over the mocs definition table to setup the register state. Refactor the
> loop construct into a reusable macro.
>
> add/remove: 2/1 grow/shrink: 1/2 up/down: 113/-330 (-217)
> Function old new   delta
> intel_mocs_init_engine.cold-  71 +71
> offset -  28 +28
> __func__   17273   17287 +14
> intel_mocs_init  143 113 -30
> mocs_register.isra91   - -91
> intel_mocs_init_engine   503 294-209
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gt/intel_mocs.c | 128 ++-
>  1 file changed, 47 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index e6f3f36a3988..63d0fdf67215 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -329,27 +329,6 @@ static bool get_mocs_settings(const struct 
> drm_i915_private *i915,
>   return true;
>  }
>  
> -static i915_reg_t mocs_register(const struct intel_engine_cs *engine, int 
> index)
> -{
> - switch (engine->id) {
> - case RCS0:
> - return GEN9_GFX_MOCS(index);
> - case VCS0:
> - return GEN9_MFX0_MOCS(index);
> - case BCS0:
> - return GEN9_BLT_MOCS(index);
> - case VECS0:
> - return GEN9_VEBOX_MOCS(index);
> - case VCS1:
> - return GEN9_MFX1_MOCS(index);
> - case VCS2:
> - return GEN11_MFX2_MOCS(index);
> - default:
> - MISSING_CASE(engine->id);
> - return INVALID_MMIO_REG;
> - }
> -}
> -
>  /*
>   * Get control_value from MOCS entry taking into account when it's not used:
>   * I915_MOCS_PTE's value is returned in this case.
> @@ -357,29 +336,47 @@ static i915_reg_t mocs_register(const struct 
> intel_engine_cs *engine, int index)
>  static u32 get_entry_control(const struct drm_i915_mocs_table *table,
>unsigned int index)
>  {
> - if (table->table[index].used)
> + if (index < table->size && table->table[index].used)
>   return table->table[index].control_value;
>  
>   return table->table[I915_MOCS_PTE].control_value;
>  }
>  
> -static void init_mocs_table(struct intel_engine_cs *engine,
> - const struct drm_i915_mocs_table *table)
> +#define for_each_mocs(mocs, t, i) \
> + for (i = 0; \
> +  i < t->n_entries ? (mocs = get_entry_control(t, i)), 1 : 0;\
> +  i++)

checkpatch might complain about some param reusage.

> +
> +static void __init_mocs_table(struct intel_uncore *uncore,
> +   const struct drm_i915_mocs_table *table,
> +   u32 addr)
>  {
> - struct intel_uncore *uncore = engine->uncore;
> - u32 unused_value = table->table[I915_MOCS_PTE].control_value;
>   unsigned int i;
> + u32 mocs;
> +
> + for_each_mocs(mocs, table, i)
> + intel_uncore_write_fw(uncore, _MMIO(addr + i * 4), mocs);
> +}
>  
> - for (i = 0; i < table->size; i++)
> - intel_uncore_write_fw(uncore,
> -   mocs_register(engine, i),
> -   get_entry_control(table, i));
> +static u32 mocs_register(const struct intel_engine_cs *engine)
> +{
> + static const u32 offset[] = {
> + [RCS0]  = 0x0c800,
> + [VCS0]  = 0x0c900,
> + [VCS1]  = 0x0ca00,
> + [VECS0] = 0x0cb00,
> + [BCS0]  = 0x0cc00,
> + [VCS2]  = 0x1,

Someone might complain about the lack of defines. Remove
the unused defines or change them to work without index.

> + };
> +
> + GEM_BUG_ON(engine->id > ARRAY_SIZE(offset));

engine->id >= ARRAY_SIZE(offset);

Also the comments throughout the file need massaging
after this change.

These 3 mocs patches looks good otherwise.

Please update resend as a separate series.

-Mika

> + return offset[engine->id];
> +}
>  
> - /* All remaining entries are unused */
> - for (; i < table->n_entries; i++)
> - intel_uncore_write_fw(uncore,
> -   mocs_register(engine, i),
> -   unused_value);
> +static void init_mocs_table(struct intel_engine_cs *engine,
> + const struct drm_i915_mocs_table *table)
> +{
> + __init_mocs_table(engine->uncore, table, mocs_register(engine));
>  }
>  
>  /*
> @@ -389,7 +386,7 @@ static void init_mocs_table(struct intel_engine_cs 
> *engine,
>  static u16 get_entry_l3cc(const struct drm_i915_mocs_table *table,
> unsigned int index)
>  {
> - if (table->table[index].used)
> 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Remove unused local variable 'file'

2019-11-12 Thread Matthew Auld

On 12/11/2019 16:36, Chris Wilson wrote:

drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c:453 igt_threaded_blt() 
error: uninitialized symbol 'file'.

Fixes: 34485832cb98 ("drm/i915/selftests: Exercise parallel blit operations on a 
single ctx")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 

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

[Intel-gfx] [PATCH 1/4] drm/i915/fbc: Nuke bogus single pipe fbc1 restriction

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Not sure where the single pipe only restriction came for fbc1.
Nothing I can see that would prevent this.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 -
 drivers/gpu/drm/i915/display/intel_fbc.c | 47 
 drivers/gpu/drm/i915/display/intel_fbc.h |  1 -
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 4 files changed, 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5f3340554149..81287ff438db 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17798,8 +17798,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
}
 
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT, wakeref);
-
-   intel_fbc_init_pipe_state(dev_priv);
 }
 
 void intel_display_resume(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 92c7eb243559..e5f4e9f23308 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -419,25 +419,6 @@ static void intel_fbc_deactivate(struct drm_i915_private 
*dev_priv,
fbc->no_fbc_reason = reason;
 }
 
-static bool multiple_pipes_ok(struct intel_crtc *crtc,
- struct intel_plane_state *plane_state)
-{
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   struct intel_fbc *fbc = _priv->fbc;
-   enum pipe pipe = crtc->pipe;
-
-   /* Don't even bother tracking anything we don't need. */
-   if (!no_fbc_on_multiple_pipes(dev_priv))
-   return true;
-
-   if (plane_state->uapi.visible)
-   fbc->visible_pipes_mask |= (1 << pipe);
-   else
-   fbc->visible_pipes_mask &= ~(1 << pipe);
-
-   return (fbc->visible_pipes_mask & ~(1 << pipe)) != 0;
-}
-
 static int find_compression_threshold(struct drm_i915_private *dev_priv,
  struct drm_mm_node *node,
  int size,
@@ -867,18 +848,12 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
 
mutex_lock(>lock);
 
-   if (!multiple_pipes_ok(crtc, plane_state)) {
-   reason = "more than one pipe active";
-   goto deactivate;
-   }
-
if (!fbc->enabled || fbc->crtc != crtc)
goto unlock;
 
intel_fbc_update_state_cache(crtc, crtc_state, plane_state);
fbc->flip_pending = true;
 
-deactivate:
intel_fbc_deactivate(dev_priv, reason);
 unlock:
mutex_unlock(>lock);
@@ -1244,28 +1219,6 @@ void intel_fbc_handle_fifo_underrun_irq(struct 
drm_i915_private *dev_priv)
schedule_work(>underrun_work);
 }
 
-/**
- * intel_fbc_init_pipe_state - initialize FBC's CRTC visibility tracking
- * @dev_priv: i915 device instance
- *
- * The FBC code needs to track CRTC visibility since the older platforms can't
- * have FBC enabled while multiple pipes are used. This function does the
- * initial setup at driver load to make sure FBC is matching the real hardware.
- */
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv)
-{
-   struct intel_crtc *crtc;
-
-   /* Don't even bother tracking anything if we don't need. */
-   if (!no_fbc_on_multiple_pipes(dev_priv))
-   return;
-
-   for_each_intel_crtc(_priv->drm, crtc)
-   if (intel_crtc_active(crtc) &&
-   crtc->base.primary->state->visible)
-   dev_priv->fbc.visible_pipes_mask |= (1 << crtc->pipe);
-}
-
 /*
  * The DDX driver changes its behavior depending on the value it reads from
  * i915.enable_fbc, so sanitize it by translating the default value into either
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h 
b/drivers/gpu/drm/i915/display/intel_fbc.h
index 50272eda8d43..ba8eeefd4d9a 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -24,7 +24,6 @@ void intel_fbc_pre_update(struct intel_crtc *crtc,
  struct intel_plane_state *plane_state);
 void intel_fbc_post_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
-void intel_fbc_init_pipe_state(struct drm_i915_private *dev_priv);
 void intel_fbc_enable(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct intel_plane_state *plane_state);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b82ff0bc6d0c..d94dd1a7ae5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -366,7 +366,6 @@ struct intel_fbc {
unsigned threshold;
unsigned int possible_framebuffer_bits;
unsigned int busy_bits;
-   unsigned int visible_pipes_mask;
struct intel_crtc *crtc;
 
struct drm_mm_node 

[Intel-gfx] [PATCH 2/4] drm/i915: Relocate intel_crtc_active()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Move intel_crtc_active() next to its only remaining
user (pre-g4x wm code).

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 81287ff438db..e7e5497e6f2e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1040,25 +1040,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state 
*crtc_state,
  NULL, best_clock);
 }
 
-bool intel_crtc_active(struct intel_crtc *crtc)
-{
-   /* Be paranoid as we can arrive here with only partial
-* state retrieved from the hardware during setup.
-*
-* We can ditch the adjusted_mode.crtc_clock check as soon
-* as Haswell has gained clock readout/fastboot support.
-*
-* We can ditch the crtc->primary->state->fb check as soon as we can
-* properly reconstruct framebuffers.
-*
-* FIXME: The intel_crtc->active here should be switched to
-* crtc->state->active once we have proper CRTC states wired up
-* for atomic.
-*/
-   return crtc->active && crtc->base.primary->state->fb &&
-   crtc->config->hw.adjusted_mode.crtc_clock;
-}
-
 enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
 enum pipe pipe)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index a5ec5eeff056..d18dc260fe83 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -558,7 +558,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
 int chv_calc_dpll_params(int refclk, struct dpll *pll_clock);
 
-bool intel_crtc_active(struct intel_crtc *crtc);
 bool hsw_crtc_state_ips_capable(const struct intel_crtc_state *crtc_state);
 void hsw_enable_ips(const struct intel_crtc_state *crtc_state);
 void hsw_disable_ips(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2d389e437e87..d5e9b935f4e7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -806,6 +806,25 @@ static bool intel_wm_plane_visible(const struct 
intel_crtc_state *crtc_state,
return plane_state->uapi.visible;
 }
 
+static bool intel_crtc_active(struct intel_crtc *crtc)
+{
+   /* Be paranoid as we can arrive here with only partial
+* state retrieved from the hardware during setup.
+*
+* We can ditch the adjusted_mode.crtc_clock check as soon
+* as Haswell has gained clock readout/fastboot support.
+*
+* We can ditch the crtc->primary->state->fb check as soon as we can
+* properly reconstruct framebuffers.
+*
+* FIXME: The intel_crtc->active here should be switched to
+* crtc->state->active once we have proper CRTC states wired up
+* for atomic.
+*/
+   return crtc->active && crtc->base.primary->state->fb &&
+   crtc->config->hw.adjusted_mode.crtc_clock;
+}
+
 static struct intel_crtc *single_enabled_crtc(struct drm_i915_private 
*dev_priv)
 {
struct intel_crtc *crtc, *enabled = NULL;
-- 
2.23.0

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

[Intel-gfx] [PATCH 3/4] drm/i915: ELiminate intel_pipe_to_cpu_transcoder() from assert_fdi_tx()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Let's start to eliminate intel_pipe_to_cpu_transcoder() so that
we can get rid of one more crtc->config usage (which we will want
to nuke as well).

In the case of assert_fdi_tx() we know that we're never
dealing with the EDP transcoder so we can simply replace
this with a cast.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e7e5497e6f2e..cabd88337822 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1141,11 +1141,15 @@ static void assert_fdi_tx(struct drm_i915_private 
*dev_priv,
  enum pipe pipe, bool state)
 {
bool cur_state;
-   enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
- pipe);
 
if (HAS_DDI(dev_priv)) {
-   /* DDI does not have a specific FDI_TX register */
+   /*
+* DDI does not have a specific FDI_TX register.
+*
+* FDI is never hooked fed from EDP transcoder
+* so pipe->transcoder cast is fine here.
+*/
+   enum transcoder cpu_transcoder = (enum transcoder)pipe;
u32 val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
cur_state = !!(val & TRANS_DDI_FUNC_ENABLE);
} else {
-- 
2.23.0

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

[Intel-gfx] [PATCH 4/4] drm/i915: Pass cpu transcoder to assert_pipe()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

In order to eliminate intel_pipe_to_cpu_transcoder() (and its
crtc->config usage) let's pass the cpu transcoder to
assert_pipe() so we don't have to do the pipe->cpu transcoder
lookup on HSW+.

On VLV/CHV this can get called during eDP init, which
happens before crtc->config->cpu_transcoder is even
populated. So currently we're always reading PIPECONF(A)
there even if we're trying to check the state of some
other pipe.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 36 
 drivers/gpu/drm/i915/display/intel_display.h |  9 +++--
 2 files changed, 18 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index cabd88337822..6d2112f5bdd0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1040,14 +1040,6 @@ bool bxt_find_best_dpll(struct intel_crtc_state 
*crtc_state,
  NULL, best_clock);
 }
 
-enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
-enum pipe pipe)
-{
-   struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
-
-   return crtc->config->cpu_transcoder;
-}
-
 static bool pipe_scanline_is_moving(struct drm_i915_private *dev_priv,
enum pipe pipe)
 {
@@ -1266,11 +1258,9 @@ void assert_panel_unlocked(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 }
 
 void assert_pipe(struct drm_i915_private *dev_priv,
-enum pipe pipe, bool state)
+enum transcoder cpu_transcoder, bool state)
 {
bool cur_state;
-   enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
- pipe);
enum intel_display_power_domain power_domain;
intel_wakeref_t wakeref;
 
@@ -1290,8 +1280,9 @@ void assert_pipe(struct drm_i915_private *dev_priv,
}
 
I915_STATE_WARN(cur_state != state,
-"pipe %c assertion failure (expected %s, current %s)\n",
-   pipe_name(pipe), onoff(state), onoff(cur_state));
+   "transcoder %s assertion failure (expected %s, current 
%s)\n",
+   transcoder_name(cpu_transcoder),
+   onoff(state), onoff(cur_state));
 }
 
 static void assert_plane(struct intel_plane *plane, bool state)
@@ -1418,7 +1409,7 @@ static void vlv_enable_pll(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
-   assert_pipe_disabled(dev_priv, pipe);
+   assert_pipe_disabled(dev_priv, pipe_config->cpu_transcoder);
 
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
@@ -1467,7 +1458,7 @@ static void chv_enable_pll(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
-   assert_pipe_disabled(dev_priv, pipe);
+   assert_pipe_disabled(dev_priv, pipe_config->cpu_transcoder);
 
/* PLL is protected by panel, make sure we can write it */
assert_panel_unlocked(dev_priv, pipe);
@@ -1514,7 +1505,7 @@ static void i9xx_enable_pll(struct intel_crtc *crtc,
u32 dpll = crtc_state->dpll_hw_state.dpll;
int i;
 
-   assert_pipe_disabled(dev_priv, crtc->pipe);
+   assert_pipe_disabled(dev_priv, crtc_state->cpu_transcoder);
 
/* PLL is protected by panel, make sure we can write it */
if (i9xx_has_pps(dev_priv))
@@ -1563,7 +1554,7 @@ static void i9xx_disable_pll(const struct 
intel_crtc_state *crtc_state)
return;
 
/* Make sure the pipe isn't still relying on us */
-   assert_pipe_disabled(dev_priv, pipe);
+   assert_pipe_disabled(dev_priv, crtc_state->cpu_transcoder);
 
I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS);
POSTING_READ(DPLL(pipe));
@@ -1574,7 +1565,7 @@ static void vlv_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
u32 val;
 
/* Make sure the pipe isn't still relying on us */
-   assert_pipe_disabled(dev_priv, pipe);
+   assert_pipe_disabled(dev_priv, (enum transcoder)pipe);
 
val = DPLL_INTEGRATED_REF_CLK_VLV |
DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
@@ -1591,7 +1582,7 @@ static void chv_disable_pll(struct drm_i915_private 
*dev_priv, enum pipe pipe)
u32 val;
 
/* Make sure the pipe isn't still relying on us */
-   assert_pipe_disabled(dev_priv, pipe);
+   assert_pipe_disabled(dev_priv, (enum transcoder)pipe);
 
val = DPLL_SSC_REF_CLK_CHV |
DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
@@ -4617,7 +4608,7 @@ static void ironlake_fdi_link_train(struct intel_crtc 
*crtc,
u32 temp, 

Re: [Intel-gfx] [PATCH] drm/i915: do not warn late about hdmi on port A

2019-11-12 Thread Matt Roper
On Fri, Nov 08, 2019 at 01:42:51PM -0800, Lucas De Marchi wrote:
> The warning should be just a warning. Where it is currently is wrong
> since we already registered the connector on drm, meaning it dies later
> on a NULL pointer deref if the VBT-overriding we have is removed. Move
> the warning up.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index e084c2f75379..ed4a68fb351f 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -3140,6 +3140,9 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   DRM_DEBUG_KMS("Adding HDMI connector on [ENCODER:%d:%s]\n",
> intel_encoder->base.base.id, intel_encoder->base.name);
>  
> + if (WARN_ON(port == PORT_A))
> + return;
> +
>   if (WARN(intel_dig_port->max_lanes < 4,
>"Not enough lanes (%d) for HDMI on [ENCODER:%d:%s]\n",
>intel_dig_port->max_lanes, intel_encoder->base.base.id,
> @@ -3159,8 +3162,6 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>  
>   intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
>  
> - if (WARN_ON(port == PORT_A))
> - return;
>   intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
>  
>   if (HAS_DDI(dev_priv))
> -- 
> 2.24.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/selftests: Remove unused local variable 'file'

2019-11-12 Thread Chris Wilson
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c:453 igt_threaded_blt() 
error: uninitialized symbol 'file'.

Fixes: 34485832cb98 ("drm/i915/selftests: Exercise parallel blit operations on 
a single ctx")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
index c8a8c07e07ab..675c1a20a2f1 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c
@@ -435,7 +435,6 @@ static int igt_threaded_blt(struct drm_i915_private *i915,
struct task_struct **tsk;
unsigned int n_cpus, i;
I915_RND_STATE(prng);
-   struct file *file;
int err = 0;
 
n_cpus = num_online_cpus() + 1;
@@ -450,7 +449,7 @@ static int igt_threaded_blt(struct drm_i915_private *i915,
 
thread[0].file = mock_file(i915);
if (IS_ERR(thread[0].file)) {
-   err = PTR_ERR(file);
+   err = PTR_ERR(thread[0].file);
goto out_thread;
}
 
-- 
2.24.0

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

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Flush gen7 even harder

2019-11-12 Thread Mika Kuoppala
Chris Wilson  writes:

> live_blt is still failing on hsw, showing the hallmark of incoherency.
> Since we are fairly certain that the interrupt is after the seqno is
> visible, the other possibility is that the seqno is before the writes to
> memory are flushed. Throw in an TLB invalidate before the breadcrumb as
> we are reasonably confident that forces a CS stall.
>
> References: f9228f765873 ("drm/i915/gt: Try an extra flush on the Haswell 
> blitter")
> References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
> Testcase: igt/i915_selftest/live_blt
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
> Try Mika's suggestion of an invalidate first.
> ---
>  drivers/gpu/drm/i915/gt/intel_ring_submission.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index fc29df712810..e8bee44add34 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -454,8 +454,9 @@ static u32 *gen7_xcs_emit_breadcrumb(struct i915_request 
> *rq, u32 *cs)
>   GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != 
> rq->engine->status_page.vma);
>   
> GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
> I915_GEM_HWS_SEQNO_ADDR);
>  
> - *cs++ = MI_FLUSH_DW;
> - *cs++ = 0;
> + *cs++ = (MI_FLUSH_DW | MI_INVALIDATE_TLB |
> +  MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW);
> + *cs++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;

If/when it doesn't work, we could try to push the invalidate to both
parts and/or tickle the same cacheline.

Acked-by: Mika Kuoppala 

>   *cs++ = 0;
>  
>   *cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
> -- 
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC-v2 4/9] drm/i915/dsi: Add cmd mode flags in display mode private flags

2019-11-12 Thread Jani Nikula
On Mon, 11 Nov 2019, Vandita Kulkarni  wrote:
> Adding TE flags and periodic command mode flags
> as part of private flags to indicate what TE interrupts
> we would be getting instead of vblanks in case of mipi dsi
> command mode.
>
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/intel_display_types.h | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index fadd9853f966..f36e8e4e5b55 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -656,6 +656,12 @@ struct intel_crtc_scaler_state {
>  #define I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP (1<<1)
>  /* Flag to use the scanline counter instead of the pixel counter */
>  #define I915_MODE_FLAG_USE_SCANLINE_COUNTER (1<<2)
> +/* Flag to use TE from DSI0 instead of VBI in command mode */
> +#define I915_MODE_FLAG_DSI_USE_TE0 (1<<3)
> +/* Flag to use TE from DSI1 instead of VBI in command mode */
> +#define I915_MODE_FLAG_DSI_USE_TE1 (1<<4)

Might be useful to comment that one or the other is set if the crtc has
a DSI encoder that's operating in command mode, and both are unset
otherwise.

Reviewed-by: Jani Nikula 

> +/* Flag to indicate mipi dsi periodic command mode where we do not get TE */
> +#define I915_MODE_FLAG_DSI_PERIODIC_CMD_MODE (1<<5)
>  
>  struct intel_pipe_wm {
>   struct intel_wm_level wm[5];

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

Re: [Intel-gfx] [RFC-v2 1/9] drm/i915/dsi: Define command mode registers

2019-11-12 Thread Jani Nikula
On Mon, 11 Nov 2019, Vandita Kulkarni  wrote:
> Adding all the register definitions needed
> for mipi dsi command mode.
>
> Signed-off-by: Madhav Chauhan 
> Signed-off-by: Vandita Kulkarni 

There may have been a few naming nitpicks I could've had, but meh.

Pushed to dinq, thanks for the patch.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/i915_reg.h | 78 +
>  1 file changed, 70 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a607ea520829..2ffcc21670b7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5036,14 +5036,20 @@ enum {
>  #define   BLM_PCH_POLARITY   (1 << 29)
>  #define BLC_PWM_PCH_CTL2 _MMIO(0xc8254)
>  
> -#define UTIL_PIN_CTL _MMIO(0x48400)
> -#define   UTIL_PIN_ENABLE(1 << 31)
> -
> -#define   UTIL_PIN_PIPE(x) ((x) << 29)
> -#define   UTIL_PIN_PIPE_MASK   (3 << 29)
> -#define   UTIL_PIN_MODE_PWM(1 << 24)
> -#define   UTIL_PIN_MODE_MASK   (0xf << 24)
> -#define   UTIL_PIN_POLARITY(1 << 22)
> +#define UTIL_PIN_CTL _MMIO(0x48400)
> +#define   UTIL_PIN_ENABLE(1 << 31)
> +#define   UTIL_PIN_PIPE_MASK (3 << 29)
> +#define   UTIL_PIN_PIPE(x)   ((x) << 29)
> +#define   UTIL_PIN_MODE_MASK (0xf << 24)
> +#define   UTIL_PIN_MODE_DATA (0 << 24)
> +#define   UTIL_PIN_MODE_PWM  (1 << 24)
> +#define   UTIL_PIN_MODE_VBLANK   (4 << 24)
> +#define   UTIL_PIN_MODE_VSYNC(5 << 24)
> +#define   UTIL_PIN_MODE_EYE_LEVEL(8 << 24)
> +#define   UTIL_PIN_OUTPUT_DATA   (1 << 23)
> +#define   UTIL_PIN_POLARITY  (1 << 22)
> +#define   UTIL_PIN_DIRECTION_INPUT   (1 << 19)
> +#define   UTIL_PIN_INPUT_DATA(1 << 16)
>  
>  /* BXT backlight register definition. */
>  #define _BXT_BLC_PWM_CTL10xC8250
> @@ -7500,11 +7506,15 @@ enum {
>  #define GEN8_DE_PORT_IMR _MMIO(0x4)
>  #define GEN8_DE_PORT_IIR _MMIO(0x8)
>  #define GEN8_DE_PORT_IER _MMIO(0xc)
> +#define  DSI1_NON_TE (1 << 31)
> +#define  DSI0_NON_TE (1 << 30)
>  #define  ICL_AUX_CHANNEL_E   (1 << 29)
>  #define  CNL_AUX_CHANNEL_F   (1 << 28)
>  #define  GEN9_AUX_CHANNEL_D  (1 << 27)
>  #define  GEN9_AUX_CHANNEL_C  (1 << 26)
>  #define  GEN9_AUX_CHANNEL_B  (1 << 25)
> +#define  DSI1_TE (1 << 24)
> +#define  DSI0_TE (1 << 23)
>  #define  BXT_DE_PORT_HP_DDIC (1 << 5)
>  #define  BXT_DE_PORT_HP_DDIB (1 << 4)
>  #define  BXT_DE_PORT_HP_DDIA (1 << 3)
> @@ -10770,6 +10780,57 @@ enum skl_power_gate {
>  #define  ICL_ESC_CLK_DIV_SHIFT   0
>  #define DSI_MAX_ESC_CLK  2   /* in KHz */
>  
> +#define _DSI_CMD_FRMCTL_00x6b034
> +#define _DSI_CMD_FRMCTL_10x6b834
> +#define DSI_CMD_FRMCTL(port) _MMIO_PORT(port,\
> +_DSI_CMD_FRMCTL_0,\
> +_DSI_CMD_FRMCTL_1)
> +#define   DSI_FRAME_UPDATE_REQUEST   (1 << 31)
> +#define   DSI_PERIODIC_FRAME_UPDATE_ENABLE   (1 << 29)
> +#define   DSI_NULL_PACKET_ENABLE (1 << 28)
> +#define   DSI_FRAME_IN_PROGRESS  (1 << 0)
> +
> +#define _DSI_INTR_MASK_REG_0 0x6b070
> +#define _DSI_INTR_MASK_REG_1 0x6b870
> +#define DSI_INTR_MASK_REG(port)  _MMIO_PORT(port,\
> +_DSI_INTR_MASK_REG_0,\
> +_DSI_INTR_MASK_REG_1)
> +
> +#define _DSI_INTR_IDENT_REG_00x6b074
> +#define _DSI_INTR_IDENT_REG_10x6b874
> +#define DSI_INTR_IDENT_REG(port) _MMIO_PORT(port,\
> +_DSI_INTR_IDENT_REG_0,\
> +_DSI_INTR_IDENT_REG_1)
> +#define   DSI_TE_EVENT   (1 << 31)
> +#define   DSI_RX_DATA_OR_BTA_TERMINATED  (1 << 30)
> +#define   DSI_TX_DATA(1 << 29)
> +#define   DSI_ULPS_ENTRY_DONE(1 << 28)
> +#define   DSI_NON_TE_TRIGGER_RECEIVED(1 << 27)
> +#define   DSI_HOST_CHKSUM_ERROR  (1 << 26)
> +#define   DSI_HOST_MULTI_ECC_ERROR   (1 << 25)
> +#define   DSI_HOST_SINGL_ECC_ERROR   (1 << 24)
> +#define   DSI_HOST_CONTENTION_DETECTED   (1 << 23)
> +#define   DSI_HOST_FALSE_CONTROL_ERROR   (1 << 22)
> +#define   DSI_HOST_TIMEOUT_ERROR (1 << 21)
> +#define   DSI_HOST_LOW_POWER_TX_SYNC_ERROR   (1 << 20)
> +#define   DSI_HOST_ESCAPE_MODE_ENTRY_ERROR   (1 << 19)
> +#define   DSI_FRAME_UPDATE_DONE  (1 << 16)
> +#define   

Re: [Intel-gfx] [RFC-v2 2/9] drm/i915/dsi: Configure transcoder operation for command mode.

2019-11-12 Thread Jani Nikula
On Mon, 11 Nov 2019, Vandita Kulkarni  wrote:
> Configure the transcoder to operate in TE GATE command mode
> and  take TE events from GPIO.
> Also disable the periodic command mode, that GOP would have
> programmed.
>
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c | 36 ++
>  1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c 
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 8eb2d7f29c82..5ff2a1ffd3ea 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -704,6 +704,10 @@ gen11_dsi_configure_transcoder(struct intel_encoder 
> *encoder,
>   tmp |= VIDEO_MODE_SYNC_PULSE;
>   break;
>   }
> + } else {
> + tmp &= ~OP_MODE_MASK;
> + tmp |= CMD_MODE_TE_GATE;
> + tmp |= TE_SOURCE_GPIO;

Do we have TE source specified in VBT or somewhere? I can live with this
*for now* but it does freak me out a bit that we might also be using the
utility pin for backlight PWM output. That would conflict magnificently.

Maybe at least add a FIXME comment about that?

>   }
>  
>   I915_WRITE(DSI_TRANS_FUNC_CONF(dsi_trans), tmp);
> @@ -953,6 +957,26 @@ static void gen11_dsi_setup_timeouts(struct 
> intel_encoder *encoder)
>   }
>  }
>  
> +static void gen11_dsi_config_util_pin(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + u32 tmp;
> +
> + /*
> +  * used as TE i/p for DSI0,
> +  * for dual link/DSI1 TE is from slave DSI1
> +  * through GPIO.
> +  */
> + if (is_vid_mode(intel_dsi) || (intel_dsi->ports & BIT(PORT_B)))
> + return;
> +
> + tmp = I915_READ(UTIL_PIN_CTL);
> + tmp |= UTIL_PIN_DIRECTION_INPUT;
> + tmp |= UTIL_PIN_ENABLE;
> + I915_WRITE(UTIL_PIN_CTL, tmp);

You'll also need to disable the utility pin somewhere, else you'll get
warnings from assert_can_enable_dc6().

> +}
> +
>  static void
>  gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config)
> @@ -974,6 +998,9 @@ gen11_dsi_enable_port_and_phy(struct intel_encoder 
> *encoder,
>   /* setup D-PHY timings */
>   gen11_dsi_setup_dphy_timings(encoder);
>  
> + /* Since transcoder is configured to take events from GPIO */
> + gen11_dsi_config_util_pin(encoder);
> +
>   /* step 4h: setup DSI protocol timeouts */
>   gen11_dsi_setup_timeouts(encoder);
>  
> @@ -1104,6 +1131,15 @@ static void gen11_dsi_deconfigure_trancoder(struct 
> intel_encoder *encoder)
>   enum transcoder dsi_trans;
>   u32 tmp;
>  
> + /* disable periodic update mode */
> + if (is_cmd_mode(intel_dsi)) {
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(DSI_CMD_FRMCTL(port));
> + tmp &= ~DSI_PERIODIC_FRAME_UPDATE_ENABLE;
> + I915_WRITE(DSI_CMD_FRMCTL(port), tmp);
> + }
> + }
> +
>   /* put dsi link in ULPS */
>   for_each_dsi_port(port, intel_dsi->ports) {
>   dsi_trans = dsi_port_to_transcoder(port);

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix detection for a CMP-V PCH

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix detection for a CMP-V PCH
URL   : https://patchwork.freedesktop.org/series/69345/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7312_full -> Patchwork_15230_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


  Here are the changes found in Patchwork_15230_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb1/igt@gem_ctx_persiste...@vcs1-queued.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-iclb7/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112146]) +8 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb7/igt@gem_exec_sched...@in-order-bsd.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-iclb2/igt@gem_exec_sched...@in-order-bsd.html

  * igt@gem_exec_schedule@out-order-bsd2:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +15 similar 
issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb1/igt@gem_exec_sched...@out-order-bsd2.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-iclb5/igt@gem_exec_sched...@out-order-bsd2.html

  * igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111832])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb2/igt@gem_exec_susp...@basic-s0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-tglb3/igt@gem_exec_susp...@basic-s0.html

  * igt@gem_mmap_gtt@hang:
- shard-snb:  [PASS][9] -> [INCOMPLETE][10] ([fdo#105411])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-snb7/igt@gem_mmap_...@hang.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-snb7/igt@gem_mmap_...@hang.html

  * igt@gem_userptr_blits@sync-unmap-after-close:
- shard-snb:  [PASS][11] -> [DMESG-WARN][12] ([fdo#111870])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-snb4/igt@gem_userptr_bl...@sync-unmap-after-close.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-snb6/igt@gem_userptr_bl...@sync-unmap-after-close.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#111830 ])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb3/igt@i915_pm...@dc6-psr.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-iclb8/igt@i915_pm...@dc6-psr.html

  * igt@i915_selftest@live_gt_timelines:
- shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([fdo#111831])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb7/igt@i915_selftest@live_gt_timelines.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-tglb9/igt@i915_selftest@live_gt_timelines.html

  * igt@kms_color@pipe-a-ctm-0-25:
- shard-skl:  [PASS][17] -> [DMESG-WARN][18] ([fdo#106107])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-skl10/igt@kms_co...@pipe-a-ctm-0-25.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-skl7/igt@kms_co...@pipe-a-ctm-0-25.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][19] -> [INCOMPLETE][20] ([fdo#110741])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl:  [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +1 
similar issue
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15230/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html
- shard-tglb: [PASS][25] -> [INCOMPLETE][26] ([fdo#111832] / 
[fdo#111850] / [fdo#111884])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb7/igt@kms_frontbuffer_track...@fbc-suspend.html
   [26]: 

Re: [Intel-gfx] [PATCH v10 2/2] drm/i915: Restrict qgv points which don't have enough bandwidth.

2019-11-12 Thread Lisovskiy, Stanislav
On Mon, 2019-11-11 at 17:22 -0800, Matt Roper wrote:
> On Thu, Nov 07, 2019 at 05:30:37PM +0200, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, we should try to
> > restrict qgv points, which can't provide
> > enough bandwidth for desired display configuration.
> > 
> > Currently we are just comparing against all of
> > those and take minimum(worst case).
> > 
> > v2: Fixed wrong PCode reply mask, removed hardcoded
> > values.
> > 
> > v3: Forbid simultaneous legacy SAGV PCode requests and
> > restricting qgv points. Put the actual restriction
> > to commit function, added serialization(thanks to Ville)
> > to prevent commit being applied out of order in case of
> > nonblocking and/or nomodeset commits.
> > 
> > v4:
> > - Minor code refactoring, fixed few typos(thanks to James
> > Ausmus)
> > - Change the naming of qgv point
> >   masking/unmasking functions(James Ausmus).
> > - Simplify the masking/unmasking operation itself,
> >   as we don't need to mask only single point per request(James
> > Ausmus)
> > - Reject and stick to highest bandwidth point if SAGV
> >   can't be enabled(BSpec)
> > 
> > v5:
> > - Add new mailbox reply codes, which seems to happen during
> > boot
> >   time for TGL and indicate that QGV setting is not yet
> > available.
> > 
> > v6:
> > - Increase number of supported QGV points to be in sync with
> > BSpec.
> > 
> > v7: - Rebased and resolved conflict to fix build failure.
> > - Fix NUM_QGV_POINTS to 8 and moved that to header file(James
> > Ausmus)
> > 
> > v8: - Don't report an error if we can't restrict qgv points, as
> > SAGV
> >   can be disabled by BIOS, which is completely legal. So don't
> >   make CI panic. Instead if we detect that there is only 1 QGV
> >   point accessible just analyze if we can fit the required
> > bandwidth
> >   requirements, but no need in restricting.
> > 
> > v9: - Fix wrong QGV transition if we have 0 planes and no SAGV
> >   simultaneously.
> > 
> > v10: - Fix CDCLK corruption, because of global state getting
> > serialized
> >without modeset, which caused copying of non-calculated
> > cdclk
> >to be copied to dev_priv(thanks to Ville for the hint).
> > 
> > Reviewed-by: James Ausmus 
> > Signed-off-by: Stanislav Lisovskiy 
> > Cc: Ville Syrjälä 
> > Cc: James Ausmus 
> > ---
> >  drivers/gpu/drm/i915/display/intel_atomic.h   |   3 +
> >  drivers/gpu/drm/i915/display/intel_bw.c   | 137
> > +++---
> >  drivers/gpu/drm/i915/display/intel_bw.h   |   2 +
> >  drivers/gpu/drm/i915/display/intel_display.c  | 104 -
> >  .../drm/i915/display/intel_display_types.h|   3 +
> >  drivers/gpu/drm/i915/i915_drv.h   |   4 +-
> >  drivers/gpu/drm/i915/i915_reg.h   |   8 +
> >  drivers/gpu/drm/i915/intel_pm.c   |  15 +-
> >  drivers/gpu/drm/i915/intel_pm.h   |   1 +
> >  drivers/gpu/drm/i915/intel_sideband.c |  27 +++-
> >  drivers/gpu/drm/i915/intel_sideband.h |   1 -
> >  11 files changed, 264 insertions(+), 41 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
> > b/drivers/gpu/drm/i915/display/intel_atomic.h
> > index 7b49623419ba..3ab6d7ec75ae 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic.h
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
> > @@ -7,6 +7,7 @@
> >  #define __INTEL_ATOMIC_H__
> >  
> >  #include 
> > +#include "intel_display_types.h"
> 
> Is this change needed?  We already have a forward declaration of
> intel_atomic_state so it doesn't seem like this should be necessary
> for
> the function prototype below.

Good point I will check if it will build without this.

> 
> > const struct intel_sa_info *sa)
> >  {
> > -   struct intel_qgv_info qi = {};
> > +   struct intel_qgv_info qi;
> 
> Is there a reason we don't want to zero out the structure here?  I
> don't
> think it should hurt anything, plus it helps prevent us from making
> mistakes in the future and trying to interpret garbage data
> associated
> with the non-existent QGV points.

I was actually planning to store it in dev_priv but then found another
way to access number of qgv points, through another structure already
stored there, then put it back, so thanks for spotting.

> 
> > bool is_y_tile = true; /* assume y tile may be used */
> > int num_channels;
> > int deinterleave;
> > @@ -270,22 +294,6 @@ void intel_bw_init_hw(struct drm_i915_private
> > *dev_priv)
> > icl_get_bw_info(dev_priv, _sa_info);
> >  }
> >  
> > -static unsigned int intel_max_data_rate(struct drm_i915_private
> > *dev_priv,
> > -   int num_planes)
> > -{
> > -   if (INTEL_GEN(dev_priv) >= 11)
> > -   /*
> > -* FIXME with SAGV disabled maybe we can assume
> > -* point 1 will always be used? Seems to match
> > -* the behaviour observed in the wild.
> > - 

Re: [Intel-gfx] [PATCH 2/9] drm/i915/bios: store child devices in a list

2019-11-12 Thread Jani Nikula
On Fri, 08 Nov 2019, Jani Nikula  wrote:
> Using the array is getting clumsy. Make things a bit more dynamic.
>
> Remove early returns on not having child devices when the end result
> after "iterating" the empty list would be the same.
>
> v3:
> - use list_add_tail to not reverse the child device list (Ville)
>
> v2:
> - stick to previous naming of child devices (Ville)
> - use kzalloc, handle failure
> - initialize list head earlier to keep intel_bios_driver_remove() safe
>
> Cc: Ville Syrjala 
> Reviewed-by: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Pushed this one, thanks for the review.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 123 ++
>  drivers/gpu/drm/i915/i915_drv.h   |   3 +-
>  2 files changed, 58 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index c19b234bebe6..7c0ca733bef8 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -58,6 +58,12 @@
>   * that.
>   */
>  
> +/* Wrapper for VBT child device config */
> +struct display_device_data {
> + struct child_device_config child;
> + struct list_head node;
> +};
> +
>  #define  SLAVE_ADDR1 0x70
>  #define  SLAVE_ADDR2 0x72
>  
> @@ -449,8 +455,9 @@ static void
>  parse_sdvo_device_mapping(struct drm_i915_private *dev_priv, u8 bdb_version)
>  {
>   struct sdvo_device_mapping *mapping;
> + const struct display_device_data *devdata;
>   const struct child_device_config *child;
> - int i, count = 0;
> + int count = 0;
>  
>   /*
>* Only parse SDVO mappings on gens that could have SDVO. This isn't
> @@ -461,8 +468,8 @@ parse_sdvo_device_mapping(struct drm_i915_private 
> *dev_priv, u8 bdb_version)
>   return;
>   }
>  
> - for (i = 0, count = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - child = dev_priv->vbt.child_dev + i;
> + list_for_each_entry(devdata, _priv->vbt.display_devices, node) {
> + child = >child;
>  
>   if (child->slave_addr != SLAVE_ADDR1 &&
>   child->slave_addr != SLAVE_ADDR2) {
> @@ -1572,8 +1579,7 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv,
>  
>  static void parse_ddi_ports(struct drm_i915_private *dev_priv, u8 
> bdb_version)
>  {
> - const struct child_device_config *child;
> - int i;
> + const struct display_device_data *devdata;
>  
>   if (!HAS_DDI(dev_priv) && !IS_CHERRYVIEW(dev_priv))
>   return;
> @@ -1581,11 +1587,8 @@ static void parse_ddi_ports(struct drm_i915_private 
> *dev_priv, u8 bdb_version)
>   if (bdb_version < 155)
>   return;
>  
> - for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> - child = dev_priv->vbt.child_dev + i;
> -
> - parse_ddi_port(dev_priv, child, bdb_version);
> - }
> + list_for_each_entry(devdata, _priv->vbt.display_devices, node)
> + parse_ddi_port(dev_priv, >child, bdb_version);
>  }
>  
>  static void
> @@ -1593,8 +1596,9 @@ parse_general_definitions(struct drm_i915_private 
> *dev_priv,
> const struct bdb_header *bdb)
>  {
>   const struct bdb_general_definitions *defs;
> + struct display_device_data *devdata;
>   const struct child_device_config *child;
> - int i, child_device_num, count;
> + int i, child_device_num;
>   u8 expected_size;
>   u16 block_size;
>   int bus_pin;
> @@ -1650,26 +1654,7 @@ parse_general_definitions(struct drm_i915_private 
> *dev_priv,
>  
>   /* get the number of child device */
>   child_device_num = (block_size - sizeof(*defs)) / defs->child_dev_size;
> - count = 0;
> - /* get the number of child device that is present */
> - for (i = 0; i < child_device_num; i++) {
> - child = child_device_ptr(defs, i);
> - if (!child->device_type)
> - continue;
> - count++;
> - }
> - if (!count) {
> - DRM_DEBUG_KMS("no child dev is parsed from VBT\n");
> - return;
> - }
> - dev_priv->vbt.child_dev = kcalloc(count, sizeof(*child), GFP_KERNEL);
> - if (!dev_priv->vbt.child_dev) {
> - DRM_DEBUG_KMS("No memory space for child device\n");
> - return;
> - }
>  
> - dev_priv->vbt.child_dev_num = count;
> - count = 0;
>   for (i = 0; i < child_device_num; i++) {
>   child = child_device_ptr(defs, i);
>   if (!child->device_type)
> @@ -1678,15 +1663,23 @@ parse_general_definitions(struct drm_i915_private 
> *dev_priv,
>   DRM_DEBUG_KMS("Found VBT child device with type 0x%x\n",
> child->device_type);
>  
> + devdata = kzalloc(sizeof(*devdata), GFP_KERNEL);
> + if (!devdata)
> + break;
> +
>   /*
>

Re: [Intel-gfx] [PATCH 1/9] drm/i915/bios: use a flag for vbt hdmi level shift presence

2019-11-12 Thread Jani Nikula
On Fri, 08 Nov 2019, Jani Nikula  wrote:
> The pre-initialized magic value is a bit silly, switch to a flag
> instead.
>
> v2: Reduce paranoia to a single sanity check (Ville)
>
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 

Pushed this one, thanks for the review (in another thread).

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/display/intel_bios.c | 10 +-
>  drivers/gpu/drm/i915/display/intel_ddi.c  | 13 +++--
>  drivers/gpu/drm/i915/i915_drv.h   |  8 ++--
>  3 files changed, 10 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index a03f56b7b4ef..c19b234bebe6 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1509,6 +1509,7 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv,
> port_name(port),
> hdmi_level_shift);
>   info->hdmi_level_shift = hdmi_level_shift;
> + info->hdmi_level_shift_set = true;
>   }
>  
>   if (bdb_version >= 204) {
> @@ -1692,8 +1693,6 @@ parse_general_definitions(struct drm_i915_private 
> *dev_priv,
>  static void
>  init_vbt_defaults(struct drm_i915_private *dev_priv)
>  {
> - enum port port;
> -
>   dev_priv->vbt.crt_ddc_pin = GMBUS_PIN_VGADDC;
>  
>   /* Default to having backlight */
> @@ -1721,13 +1720,6 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
>   dev_priv->vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev_priv,
>   !HAS_PCH_SPLIT(dev_priv));
>   DRM_DEBUG_KMS("Set default to SSC at %d kHz\n", 
> dev_priv->vbt.lvds_ssc_freq);
> -
> - for_each_port(port) {
> - struct ddi_vbt_port_info *info =
> - _priv->vbt.ddi_port_info[port];
> -
> - info->hdmi_level_shift = HDMI_LEVEL_SHIFT_UNKNOWN;
> - }
>  }
>  
>  /* Defaults to initialize only if there is no VBT. */
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 092f0341d8d4..1441672c5611 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -888,11 +888,10 @@ icl_get_combo_buf_trans(struct drm_i915_private 
> *dev_priv, int type, int rate,
>  
>  static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv, enum port 
> port)
>  {
> + struct ddi_vbt_port_info *port_info = 
> _priv->vbt.ddi_port_info[port];
>   int n_entries, level, default_entry;
>   enum phy phy = intel_port_to_phy(dev_priv, port);
>  
> - level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
> -
>   if (INTEL_GEN(dev_priv) >= 12) {
>   if (intel_phy_is_combo(dev_priv, phy))
>   icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
> @@ -927,12 +926,14 @@ static int intel_ddi_hdmi_level(struct drm_i915_private 
> *dev_priv, enum port por
>   return 0;
>   }
>  
> - /* Choose a good default if VBT is badly populated */
> - if (level == HDMI_LEVEL_SHIFT_UNKNOWN || level >= n_entries)
> - level = default_entry;
> -
>   if (WARN_ON_ONCE(n_entries == 0))
>   return 0;
> +
> + if (port_info->hdmi_level_shift_set)
> + level = port_info->hdmi_level_shift;
> + else
> + level = default_entry;
> +
>   if (WARN_ON_ONCE(level >= n_entries))
>   level = n_entries - 1;
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7e0f67babe20..67bdfe6de3fa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -627,13 +627,9 @@ struct ddi_vbt_port_info {
>  
>   int max_tmds_clock;
>  
> - /*
> -  * This is an index in the HDMI/DVI DDI buffer translation table.
> -  * The special value HDMI_LEVEL_SHIFT_UNKNOWN means the VBT didn't
> -  * populate this field.
> -  */
> -#define HDMI_LEVEL_SHIFT_UNKNOWN 0xff
> + /* This is an index in the HDMI/DVI DDI buffer translation table. */
>   u8 hdmi_level_shift;
> + u8 hdmi_level_shift_set:1;
>  
>   u8 supports_dvi:1;
>   u8 supports_hdmi:1;

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

[Intel-gfx] [PATCH v2] drm/i915/gt: Flush gen7 even harder

2019-11-12 Thread Chris Wilson
live_blt is still failing on hsw, showing the hallmark of incoherency.
Since we are fairly certain that the interrupt is after the seqno is
visible, the other possibility is that the seqno is before the writes to
memory are flushed. Throw in an TLB invalidate before the breadcrumb as
we are reasonably confident that forces a CS stall.

References: f9228f765873 ("drm/i915/gt: Try an extra flush on the Haswell 
blitter")
References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
Testcase: igt/i915_selftest/live_blt
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
Try Mika's suggestion of an invalidate first.
---
 drivers/gpu/drm/i915/gt/intel_ring_submission.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index fc29df712810..e8bee44add34 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -454,8 +454,9 @@ static u32 *gen7_xcs_emit_breadcrumb(struct i915_request 
*rq, u32 *cs)
GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != 
rq->engine->status_page.vma);

GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);
 
-   *cs++ = MI_FLUSH_DW;
-   *cs++ = 0;
+   *cs++ = (MI_FLUSH_DW | MI_INVALIDATE_TLB |
+MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW);
+   *cs++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
*cs++ = 0;
 
*cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
-- 
2.24.0

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

Re: [Intel-gfx] [PATCH v10 1/2] drm/i915: Refactor intel_can_enable_sagv

2019-11-12 Thread Lisovskiy, Stanislav
On Mon, 2019-11-11 at 16:15 -0800, Matt Roper wrote:
> On Thu, Nov 07, 2019 at 05:30:36PM +0200, Stanislav Lisovskiy wrote:
> > Currently intel_can_enable_sagv function contains
> > a mix of workarounds for different platforms
> > some of them are not valid for gens >= 11 already,
> > so lets split it into separate functions.
> > 
> > v2:
> > - Rework watermark calculation algorithm to
> >   attempt to calculate Level 0 watermark
> >   with added sagv block time latency and
> >   check if it fits in DBuf in order to
> >   determine if SAGV can be enabled already
> >   at this stage, just as BSpec 49325 states.
> >   if that fails rollback to usual Level 0
> >   latency and disable SAGV.
> > - Remove unneeded tabs(James Ausmus)
> > 
> > v3: Rebased the patch
> > 
> > v4: - Added back interlaced check for Gen12 and
> >   added separate function for TGL SAGV check
> >   (thanks to James Ausmus for spotting)
> > - Removed unneeded gen check
> > - Extracted Gen12 SAGV decision making code
> >   to a separate function from skl_compute_wm
> > 
> > v5: - Added SAGV global state to dev_priv, because
> >   we need to track all pipes, not only those
> >   in atomic state. Each pipe has now correspondent
> >   bit mask reflecting, whether it can tolerate
> >   SAGV or not(thanks to Ville Syrjala for suggestions).
> > - Now using active flag instead of enable in crc
> >   usage check.
> > 
> > v6: - Fixed rebase conflicts
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > Cc: Ville Syrjälä 
> > Cc: James Ausmus 
> > ---
> >  drivers/gpu/drm/i915/display/intel_display.c  |   4 +
> >  .../drm/i915/display/intel_display_types.h|   9 +
> >  drivers/gpu/drm/i915/i915_drv.h   |   6 +
> >  drivers/gpu/drm/i915/intel_pm.c   | 296
> > +-
> >  4 files changed, 303 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 876fc25968bf..7ea1e7518ab6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -14855,6 +14855,10 @@ static void
> > intel_atomic_commit_tail(struct intel_atomic_state *state)
> > if (dev_priv->display.optimize_watermarks)
> > dev_priv->display.optimize_watermarks(state,
> >   new_crtc_
> > state);
> > +   if (state->crtc_sagv_mask & BIT(crtc->pipe))
> > +   dev_priv->crtc_sagv_mask |= BIT(crtc->pipe);
> > +   else
> > +   dev_priv->crtc_sagv_mask &= ~BIT(crtc->pipe);
> > }
> >  
> > for_each_oldnew_intel_crtc_in_state(state, crtc,
> > old_crtc_state, new_crtc_state, i) {
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index fadd9853f966..fb274538af23 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -490,6 +490,14 @@ struct intel_atomic_state {
> >  */
> > u8 active_pipe_changes;
> >  
> > +   /*
> > +* Contains a mask which reflects whether correspondent pipe
> > +* can tolerate SAGV or not, so that we can make a decision
> > +* at atomic_commit_tail stage, whether we enable it or not
> > +* based on global state in dev_priv.
> > +*/
> > +   u32 crtc_sagv_mask;
> > +
> > u8 active_pipes;
> > /* minimum acceptable cdclk for each pipe */
> > int min_cdclk[I915_MAX_PIPES];
> > @@ -670,6 +678,7 @@ struct skl_plane_wm {
> > struct skl_wm_level wm[8];
> > struct skl_wm_level uv_wm[8];
> > struct skl_wm_level trans_wm;
> > +   struct skl_wm_level sagv_wm0;
> > bool is_planar;
> >  };
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 7e0f67babe20..4f4e2e839513 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1176,6 +1176,12 @@ struct drm_i915_private {
> >  
> > u32 sagv_block_time_us;
> >  
> > +   /*
> > +* Contains a bit mask, whether correspondent
> > +* pipe allows SAGV or not.
> > +*/
> > +   u32 crtc_sagv_mask;
> > +
> > struct {
> > /*
> >  * Raw watermark latency values:
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 2d389e437e87..c792dd168742 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3740,7 +3740,7 @@ intel_disable_sagv(struct drm_i915_private
> > *dev_priv)
> > return 0;
> >  }
> >  
> > -bool intel_can_enable_sagv(struct intel_atomic_state *state)
> > +static void skl_set_sagv_mask(struct intel_atomic_state *state)
> >  {
> > struct drm_device *dev = state->base.dev;
> > struct drm_i915_private 

Re: [Intel-gfx] [PATCH v2] drm/i915: Flush context free work on cleanup

2019-11-12 Thread Mika Kuoppala
Chris Wilson  writes:

> Throw in a flush_work() to specifically flush the context cleanup work
> before the module is unloaded.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112248
> Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 72d389afa28a..17f395672e5e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -776,6 +776,7 @@ int i915_gem_init_contexts(struct drm_i915_private *i915)
>  void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
>  {
>   destroy_kernel_context(>kernel_context);
> + flush_work(>gem.contexts.free_work);
>  }
>  
>  static int context_idr_cleanup(int id, void *p, void *data)
> -- 
> 2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] i915: Mark up a few more tests that only target GGTT

2019-11-12 Thread Chris Wilson
If a test is only targeting the GGTT API and its corner cases, it can
only run if we have a mappable aperture.

Signed-off-by: Chris Wilson 
Cc: Antonio Argenziano 
---
 lib/i915/gem_mman.c | 19 +++
 lib/i915/gem_mman.h |  3 +++
 tests/i915/gem_gtt_cpu_tlb.c|  1 +
 tests/i915/gem_gtt_hog.c|  1 +
 tests/i915/gem_gtt_speed.c  |  2 ++
 tests/i915/gem_mmap_gtt.c   |  5 +
 tests/i915/gem_tiled_swapping.c |  1 +
 7 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 3cf9a6bbd..76d0be82e 100644
--- a/lib/i915/gem_mman.c
+++ b/lib/i915/gem_mman.c
@@ -252,3 +252,22 @@ void *gem_mmap__cpu(int fd, uint32_t handle, uint64_t 
offset, uint64_t size, uns
igt_assert(ptr);
return ptr;
 }
+
+bool gem_has_ggtt(int i915)
+{
+   struct drm_i915_gem_mmap_gtt arg = {};
+   int err;
+
+   err = 0;
+   if (ioctl(i915, DRM_IOCTL_I915_GEM_MMAP_GTT, ))
+   err = errno;
+   errno = 0;
+
+   return errno != ENODEV;
+}
+
+void gem_require_ggtt(int i915)
+{
+   igt_require_f(gem_has_ggtt(i915),
+ "HW & kernel support for indirect detiling aperture\n");
+}
diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
index f7242ed77..67891c8de 100644
--- a/lib/i915/gem_mman.h
+++ b/lib/i915/gem_mman.h
@@ -35,6 +35,9 @@ void *gem_mmap__wc(int fd, uint32_t handle, uint64_t offset, 
uint64_t size, unsi
 #define I915_GEM_DOMAIN_WC 0x80
 #endif
 
+bool gem_has_ggtt(int i915);
+void gem_require_ggtt(int i915);
+
 void *__gem_mmap__gtt(int fd, uint32_t handle, uint64_t size, unsigned prot);
 void *__gem_mmap__cpu(int fd, uint32_t handle, uint64_t offset, uint64_t size, 
unsigned prot);
 void *__gem_mmap__wc(int fd, uint32_t handle, uint64_t offset, uint64_t size, 
unsigned prot);
diff --git a/tests/i915/gem_gtt_cpu_tlb.c b/tests/i915/gem_gtt_cpu_tlb.c
index cf3c543df..a4cbb1034 100644
--- a/tests/i915/gem_gtt_cpu_tlb.c
+++ b/tests/i915/gem_gtt_cpu_tlb.c
@@ -79,6 +79,7 @@ igt_simple_main
igt_skip_on_simulation();
 
fd = drm_open_driver(DRIVER_INTEL);
+   gem_require_ggtt(fd);
 
handle = gem_create(fd, OBJ_SIZE);
 
diff --git a/tests/i915/gem_gtt_hog.c b/tests/i915/gem_gtt_hog.c
index ca730649c..7a6273936 100644
--- a/tests/i915/gem_gtt_hog.c
+++ b/tests/i915/gem_gtt_hog.c
@@ -161,6 +161,7 @@ igt_simple_main
/* check for an intel gpu before goint nuts. */
int fd = drm_open_driver(DRIVER_INTEL);
igt_require_gem(fd);
+   gem_require_ggtt(fd);
close(fd);
 
igt_skip_on_simulation();
diff --git a/tests/i915/gem_gtt_speed.c b/tests/i915/gem_gtt_speed.c
index dfa7216cc..0cdd51dc3 100644
--- a/tests/i915/gem_gtt_speed.c
+++ b/tests/i915/gem_gtt_speed.c
@@ -124,7 +124,9 @@ igt_simple_main_args("s:", NULL, help_str, opt_handler, 
NULL)
 
buf = malloc(size);
memset(buf, 0, size);
+
fd = drm_open_driver(DRIVER_INTEL);
+   gem_require_ggtt(fd);
 
handle = gem_create(fd, size);
igt_assert(handle);
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index ac25f13e2..d31c73ed4 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -1020,8 +1020,6 @@ igt_main
OBJECT_SIZE = 1 * 1024 * 1024;
 
igt_fixture {
-   struct drm_i915_gem_mmap_gtt arg = {};
-
fd = drm_open_driver(DRIVER_INTEL);
 
/*
@@ -1029,8 +1027,7 @@ igt_main
 * detiling access from untrusted userspace to the objects,
 * the kernel does an early rejection of the mmap_gtt ioctl.
 */
-   igt_require_f(mmap_ioctl(fd, ) != -ENODEV,
- "HW & kernel support for indirect detiling 
aperture\n");
+   gem_require_ggtt(fd);
}
 
igt_subtest("bad-object") {
diff --git a/tests/i915/gem_tiled_swapping.c b/tests/i915/gem_tiled_swapping.c
index 1b70c1e51..3a95c9469 100644
--- a/tests/i915/gem_tiled_swapping.c
+++ b/tests/i915/gem_tiled_swapping.c
@@ -175,6 +175,7 @@ igt_main
current_tiling_mode = I915_TILING_X;
 
fd = drm_open_driver(DRIVER_INTEL);
+   gem_require_ggtt(fd);
 
intel_purge_vm_caches(fd);
check_memory_layout(fd);
-- 
2.24.0

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Cleanups around .crtc_enable/disable()

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Cleanups around .crtc_enable/disable()
URL   : https://patchwork.freedesktop.org/series/69352/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7316 -> Patchwork_15234


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15234 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15234, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_15234:

### IGT changes ###

 Possible regressions 

  * igt@prime_vgem@basic-sync-default:
- fi-bdw-5557u:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-bdw-5557u/igt@prime_v...@basic-sync-default.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/fi-bdw-5557u/igt@prime_v...@basic-sync-default.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html

  
Known issues


  Here are the changes found in Patchwork_15234 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_gtt:
- fi-skl-6600u:   [PASS][5] -> [TIMEOUT][6] ([fdo#111732 ])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-skl-6600u/igt@i915_selftest@live_gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/fi-skl-6600u/igt@i915_selftest@live_gtt.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([fdo#111407])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-skl-6770hq:  [PASS][9] -> [WARN][10] ([fdo#112252])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/fi-skl-6770hq/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[SKIP][11] ([fdo#109271]) -> [PASS][12] +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html

  * igt@i915_selftest@live_execlists:
- {fi-kbl-7560u}: [INCOMPLETE][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-kbl-7560u/igt@i915_selftest@live_execlists.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15234/fi-kbl-7560u/igt@i915_selftest@live_execlists.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
  [fdo#111732 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111732 
  [fdo#112252]: https://bugs.freedesktop.org/show_bug.cgi?id=112252


Participating hosts (52 -> 45)
--

  Additional (1): fi-gdg-551 
  Missing(8): fi-hsw-4770r fi-ilk-m540 fi-tgl-u fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-byt-clapper fi-bdw-samus 


Build changes
-

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_7316 -> Patchwork_15234

  CI-20190529: 20190529
  CI_DRM_7316: a4939708275196364ef98691a90c89d501536494 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5272: 5997df31db10f190fe8b70d920b6a6b8d3b24126 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_15234: 9899c3878df3b2492027074eca2fa393a9bd0849 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

9899c3878df3 drm/i915: Change .crtc_enable/disable() calling convention
657718a9bff8 drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable()
3b0a98a39380 drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable()
4f42f6bd0ad8 drm/i915: Pass dev_priv to 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Explicitly cleanup initial_plane_config

2019-11-12 Thread Chris Wilson
Quoting Ville Syrjälä (2019-11-12 15:20:52)
> On Tue, Nov 12, 2019 at 02:36:42PM +, Chris Wilson wrote:
> > @@ -3317,7 +3313,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> > *intel_crtc,
> >   if (plane_config->tiling)
> >   dev_priv->preserve_bios_swizzle = true;
> >  
> > - plane_state->fb = fb;
> 
> This stuff looks wrong. We still want the plane state to point at the
> fb.

Oh, it used to be

@@ -3266,8 +3262,9 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
if (plane_config->tiling)
dev_priv->preserve_bios_swizzle = true;

-   plane_state->fb = fb;
plane_state->crtc = _crtc->base;
+   plane_state->fb = fb;
+   drm_framebuffer_get(fb);

atomic_or(to_intel_plane(primary)->frontbuffer_bit,
  _intel_frontbuffer(fb)->bits);

I'll blame it on not paying enough attention during the rebase.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND 0/8] drm/print: cleanup and new drm_device based logging

2019-11-12 Thread Sean Paul
On Mon, Oct 28, 2019 at 12:38:14PM +0200, Jani Nikula wrote:
> Resend of [1]; I may have rebased but I'm not sure anymore...
> 
> For starters some fairly benign cleanup, and a proposal for new struct
> drm_device based drm logging macros analoguous to core kernel struct
> device based macros.
> 
> Please let's at least get the first 7 reviewed/acked/merged, shall we?
> 

Acked-by: Sean Paul 

> 
> BR,
> Jani.
> 
> 
> [1] https://patchwork.freedesktop.org/series/67795/
> 
> 
> Jani Nikula (8):
>   drm/i915: use drm_debug_enabled() to check for debug categories
>   drm/nouveau: use drm_debug_enabled() to check for debug categories
>   drm/amdgpu: use drm_debug_enabled() to check for debug categories
>   drm/print: rename drm_debug to __drm_debug to discourage use
>   drm/print: underscore prefix functions that should be private to print
>   drm/print: convert debug category macros into an enum
>   drm/print: group logging functions by prink or device based
>   drm/print: introduce new struct drm_device based logging macros
> 
>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c   |   4 +-
>  drivers/gpu/drm/drm_print.c  |  18 +-
>  drivers/gpu/drm/i915/display/intel_display.c |   4 +-
>  drivers/gpu/drm/i915/display/intel_dp.c  |   2 +-
>  drivers/gpu/drm/i915/i915_drv.c  |   2 +-
>  drivers/gpu/drm/i915/i915_gem.h  |   2 +-
>  drivers/gpu/drm/i915/i915_utils.c|   2 +-
>  drivers/gpu/drm/i915/intel_pm.c  |   2 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.h  |   4 +-
>  drivers/gpu/drm/nouveau/nouveau_drv.h|   4 +-
>  include/drm/drm_print.h  | 304 ---
>  11 files changed, 224 insertions(+), 124 deletions(-)
> 
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Flush all user surfaces prior to first use

2019-11-12 Thread Chris Wilson
Since userspace has the ability to bypass the CPU cache from within its
unprivileged command stream, we have to flush the CPU cache to memory
in order to overwrite the previous contents on creation. We enforce this
at the boundary points (get/put pages) to ensure that before recycling
system pages we are always cache coherent.

v3: We now always clflush on acquisition and release of system pages,
and include a clflush counting selftest to make sure we do. This also
succinctly covers swap-in/swap-out.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Ville Syrjälä 
Cc: Francisco Jerez 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_clflush.c   |   8 ++
 drivers/gpu/drm/i915/gem/i915_gem_clflush.h   |   6 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   7 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  22 +++-
 .../i915/gem/selftests/i915_gem_coherency.c   | 113 ++
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 6 files changed, 153 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index b9f504ba3b32..e2434e17ffc1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -16,11 +16,19 @@ struct clflush {
struct drm_i915_gem_object *obj;
 };
 
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+void st_clflush_inc(struct drm_i915_gem_object *obj)
+{
+   atomic_inc(_i915(obj->base.dev)->gem.clflushes);
+}
+#endif
+
 static void __do_clflush(struct drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
drm_clflush_sg(obj->mm.pages);
intel_frontbuffer_flush(obj->frontbuffer, ORIGIN_CPU);
+   st_clflush_inc(obj);
 }
 
 static int clflush_work(struct dma_fence_work *base)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h 
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
index e6c382973129..7434d878a553 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.h
@@ -17,4 +17,10 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object *obj,
 #define I915_CLFLUSH_FORCE BIT(0)
 #define I915_CLFLUSH_SYNC BIT(1)
 
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+void st_clflush_inc(struct drm_i915_gem_object *obj);
+#else
+static inline void st_clflush_inc(struct drm_i915_gem_object *obj) { }
+#endif
+
 #endif /* __I915_GEM_CLFLUSH_H__ */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index f402c2c415c2..8bcf9b65d661 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -5,9 +5,10 @@
  */
 
 #include "i915_drv.h"
+#include "i915_gem_clflush.h"
+#include "i915_gem_lmem.h"
 #include "i915_gem_object.h"
 #include "i915_scatterlist.h"
-#include "i915_gem_lmem.h"
 
 void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
 struct sg_table *pages,
@@ -25,8 +26,10 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object 
*obj,
/* Make the pages coherent with the GPU (flushing any swapin). */
if (obj->cache_dirty) {
obj->write_domain = 0;
-   if (i915_gem_object_has_struct_page(obj))
+   if (i915_gem_object_has_struct_page(obj)) {
drm_clflush_sg(pages);
+   st_clflush_inc(obj);
+   }
obj->cache_dirty = false;
}
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 4d69c3fc3439..9db53a4d1b2e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -10,6 +10,7 @@
 #include "gem/i915_gem_region.h"
 #include "i915_drv.h"
 #include "i915_gemfs.h"
+#include "i915_gem_clflush.h"
 #include "i915_gem_object.h"
 #include "i915_scatterlist.h"
 #include "i915_trace.h"
@@ -183,6 +184,15 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj, st);
 
+   /*
+* Since userspace has the ability to bypass the CPU cache from within
+* its unprivileged command stream, we have to flush the CPU cache to
+* memory in order to overwrite the previous contents on creation, so
+* that userspace cannot snoop on the old system pages just handed to
+* us.
+*/
+   obj->cache_dirty = true; /* For drm_clflush_sg() inside set_pages */
+
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
 
return 0;
@@ -285,10 +295,16 @@ __i915_gem_object_release_shmem(struct 
drm_i915_gem_object *obj,
if (obj->mm.madv == I915_MADV_DONTNEED)
obj->mm.dirty = false;
 
-   if (needs_clflush &&
-   (obj->read_domains & I915_GEM_DOMAIN_CPU) == 0 &&
-   !(obj->cache_coherent & 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Explicitly cleanup initial_plane_config

2019-11-12 Thread Ville Syrjälä
On Tue, Nov 12, 2019 at 02:36:42PM +, Chris Wilson wrote:
> I am about to stuff more objects into the plane_config and would like to
> have it clean up after itself. Move the current framebuffer release into
> a common function so it can be extended with the new object with
> relative ease.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5f3340554149..f571c6575c62 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3241,8 +3241,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>   goto valid_fb;
>   }
>  
> - kfree(plane_config->fb);
> -
>   /*
>* Failed to alloc the obj, check to see if we should share
>* an fb with another CRTC instead
> @@ -3262,7 +3260,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>  
>   if (intel_plane_ggtt_offset(state) == plane_config->base) {
>   fb = state->hw.fb;
> - drm_framebuffer_get(fb);
>   goto valid_fb;
>   }
>   }
> @@ -3295,7 +3292,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
> intel_crtc->pipe, PTR_ERR(intel_state->vma));
>  
>   intel_state->vma = NULL;
> - drm_framebuffer_put(fb);
>   return;
>   }
>  
> @@ -3317,7 +3313,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
> *intel_crtc,
>   if (plane_config->tiling)
>   dev_priv->preserve_bios_swizzle = true;
>  
> - plane_state->fb = fb;

This stuff looks wrong. We still want the plane state to point at the
fb.

Ideally I'd like to nuke the plane_config thing entirely and just read
everything directly into the plane_states(s), but that's probably a
bunch of actual work so not going to happen soon.

>   plane_state->crtc = _crtc->base;
>   intel_plane_copy_uapi_to_hw_state(intel_state, intel_state);
>  
> @@ -16952,6 +16947,19 @@ static void intel_mode_config_init(struct 
> drm_i915_private *i915)
>   }
>  }
>  
> +static void plane_config_fini(struct intel_initial_plane_config 
> *plane_config)
> +{
> + if (plane_config->fb) {
> + struct drm_framebuffer *fb = _config->fb->base;
> +
> + /* We may only have the stub and not a full framebuffer */
> + if (drm_framebuffer_read_refcount(fb))
> + drm_framebuffer_put(fb);
> + else
> + kfree(fb);
> + }
> +}
> +
>  int intel_modeset_init(struct drm_i915_private *i915)
>  {
>   struct drm_device *dev = >drm;
> @@ -17036,6 +17044,8 @@ int intel_modeset_init(struct drm_i915_private *i915)
>* just get the first one.
>*/
>   intel_find_initial_plane_obj(crtc, _config);
> +
> + plane_config_fini(_config);
>   }
>  
>   /*
> -- 
> 2.24.0

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

[Intel-gfx] [PATCH] drm/i915/gt: More delays for gen7 flushing

2019-11-12 Thread Chris Wilson
live_blt is still failing on hsw, showing the hallmark of incoherency.
Since we are fairly certain that the interrupt is after the seqno is
visible, the other possibility is that the seqno is before the writes to
memory are flushed. Throw in some more MI_FLUSH_DW before the breadcrumb
to try and flush any internal pipelines.

References: f9228f765873 ("drm/i915/gt: Try an extra flush on the Haswell 
blitter")
References: https://bugs.freedesktop.org/show_bug.cgi?id=112147
Testcase: igt/i915_selftest/live_blt
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gt/intel_ring_submission.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index fc29df712810..14d115891ed9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -454,9 +454,11 @@ static u32 *gen7_xcs_emit_breadcrumb(struct i915_request 
*rq, u32 *cs)
GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != 
rq->engine->status_page.vma);

GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != 
I915_GEM_HWS_SEQNO_ADDR);
 
-   *cs++ = MI_FLUSH_DW;
-   *cs++ = 0;
-   *cs++ = 0;
+   for (i = 0; i < 7; i++) {
+   *cs++ = MI_FLUSH_DW;
+   *cs++ = 0;
+   *cs++ = 0;
+   }
 
*cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
*cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
-- 
2.24.0

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flush all user surfaces prior to first use (rev3)

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Flush all user surfaces prior to first use (rev3)
URL   : https://patchwork.freedesktop.org/series/63871/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7316 -> Patchwork_15233


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15233 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15233, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_15233:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_coherency:
- fi-skl-6770hq:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-skl-6770hq/igt@i915_selftest@live_coherency.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-skl-6770hq/igt@i915_selftest@live_coherency.html
- fi-byt-n2820:   [PASS][3] -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-byt-n2820/igt@i915_selftest@live_coherency.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-byt-n2820/igt@i915_selftest@live_coherency.html
- fi-skl-6700k2:  [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-skl-6700k2/igt@i915_selftest@live_coherency.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-skl-6700k2/igt@i915_selftest@live_coherency.html
- fi-skl-lmem:[PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-skl-lmem/igt@i915_selftest@live_coherency.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-skl-lmem/igt@i915_selftest@live_coherency.html
- fi-snb-2600:[PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-snb-2600/igt@i915_selftest@live_coherency.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-snb-2600/igt@i915_selftest@live_coherency.html
- fi-hsw-peppy:   [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-hsw-peppy/igt@i915_selftest@live_coherency.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-hsw-peppy/igt@i915_selftest@live_coherency.html
- fi-kbl-x1275:   [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-kbl-x1275/igt@i915_selftest@live_coherency.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-kbl-x1275/igt@i915_selftest@live_coherency.html
- fi-icl-u3:  [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-icl-u3/igt@i915_selftest@live_coherency.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-icl-u3/igt@i915_selftest@live_coherency.html
- fi-bwr-2160:[PASS][17] -> [DMESG-FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-bwr-2160/igt@i915_selftest@live_coherency.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-bwr-2160/igt@i915_selftest@live_coherency.html
- fi-kbl-r:   [PASS][19] -> [DMESG-WARN][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-kbl-r/igt@i915_selftest@live_coherency.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-kbl-r/igt@i915_selftest@live_coherency.html
- fi-skl-guc: [PASS][21] -> [DMESG-WARN][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-skl-guc/igt@i915_selftest@live_coherency.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-skl-guc/igt@i915_selftest@live_coherency.html
- fi-kbl-8809g:   [PASS][23] -> [DMESG-WARN][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-kbl-8809g/igt@i915_selftest@live_coherency.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-kbl-8809g/igt@i915_selftest@live_coherency.html
- fi-bsw-nick:[PASS][25] -> [DMESG-FAIL][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-bsw-nick/igt@i915_selftest@live_coherency.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-bsw-nick/igt@i915_selftest@live_coherency.html
- fi-snb-2520m:   [PASS][27] -> [DMESG-WARN][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7316/fi-snb-2520m/igt@i915_selftest@live_coherency.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15233/fi-snb-2520m/igt@i915_selftest@live_coherency.html
- fi-bxt-dsi: [PASS][29] -> 

Re: [Intel-gfx] [RFC-v2 8/9] drm/i915/dsi: Add TE handler for dsi cmd mode.

2019-11-12 Thread Jani Nikula
On Mon, 11 Nov 2019, Vandita Kulkarni  wrote:
> In case of dual link, we get the TE on slave.
> So clear the TE on slave DSI IIR.
>
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 62 +
>  1 file changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f27afde409bf..34a06876a2d7 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2230,6 +2230,62 @@ gen8_de_misc_irq_handler(struct drm_i915_private 
> *dev_priv, u32 iir)
>   DRM_ERROR("Unexpected DE Misc interrupt\n");
>  }
>  
> +void gen11_dsi_te_interrupt_handler(struct drm_i915_private *dev_priv,
> + u32 iir_value)
> +{
> + enum pipe pipe = INVALID_PIPE;
> + enum transcoder dsi_trans;
> + enum port port;
> + u32 val, tmp;
> +
> + /*
> +  * Incase of dual link, TE comes from DSI_1
> +  * this is to check if dual link is enabled
> +  */
> + val = I915_READ(TRANS_DDI_FUNC_CTL2(TRANSCODER_DSI_0));
> + val &= PORT_SYNC_MODE_ENABLE;
> +
> + /*
> +  * if dual link is enabled, then read DSI_0
> +  * transcoder registers
> +  */
> + port = ((iir_value & DSI1_TE && val) || (iir_value & DSI0_TE)) ?
> + PORT_A : PORT_B;
> + dsi_trans = (port == PORT_A) ? TRANSCODER_DSI_0 : TRANSCODER_DSI_1;
> +
> + /* Check if DSI configured in command mode */
> + val = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
> + val = (val & OP_MODE_MASK) >> 28;
> +
> + if (val) {
> + DRM_ERROR("DSI trancoder not configured in command mode\n");
> + return;
> + }
> +
> + /* Get PIPE for handling VBLANK event */
> + val = I915_READ(TRANS_DDI_FUNC_CTL(dsi_trans));
> + switch (val & TRANS_DDI_EDP_INPUT_MASK) {
> + case TRANS_DDI_EDP_INPUT_A_ON:
> + pipe = PIPE_A;
> + break;
> + case TRANS_DDI_EDP_INPUT_B_ONOFF:
> + pipe = PIPE_B;
> + break;
> + case TRANS_DDI_EDP_INPUT_C_ONOFF:
> + pipe = PIPE_C;
> + break;
> + default:
> + DRM_ERROR("Invalid PIPE\n");
> + }
> +
> + /* clear TE in dsi IIR */
> + port = (iir_value & DSI1_TE) ? PORT_B : PORT_A;
> + tmp = I915_READ(DSI_INTR_IDENT_REG(port));
> + I915_WRITE(DSI_INTR_IDENT_REG(port), tmp);
> +
> + drm_handle_vblank(_priv->drm, pipe);
> +}
> +
>  static irqreturn_t
>  gen8_de_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl)
>  {
> @@ -2294,6 +2350,12 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   found = true;
>   }
>  
> + if ((INTEL_GEN(dev_priv) >= 11) &&
> + (iir & (DSI0_TE | DSI1_TE))) {

Please follow the same style as nearby:

if (gen11) {
tmp_mask = iir & (DSI0_TE | DSI1_TE);
if (tmp_mask) {
gen11_dsi_te_interrupt_handler(dev_priv, tmp_mask);
found = true;
}
}

Even if that's functionally the same, I think it's cleaner to only pass
the relevant masked bits to the handler.


> + gen11_dsi_te_interrupt_handler(dev_priv, iir);
> + found = true;
> + }
> +
>   if (!found)
>   DRM_ERROR("Unexpected DE Port interrupt\n");
>   }

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

[Intel-gfx] drm core/helpers and MIT license

2019-11-12 Thread Daniel Vetter
Hi all,

Dave and me chatted about this last week on irc. Essentially we have:

$ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */
drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_gem_framebuffer_helper.c://
SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later
drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only
drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier:
GPL-2.0-or-later
drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0

One is GPL+MIT, so ok, and one is a default GPL-only header from
Greg's infamous patch (so could probably be changed to MIT license
header). I only looked at .c sources, since headers are worse wrt
having questionable default headers. So about 18 files with clear GPL
licenses thus far in drm core/helpers.

Looking at where that code came from, it is mostly from GPL-only
drivers (we have a lot of those nowadays), so seems legit non-MIT
licensed. Question is now what do we do:

- Nothing, which means GPL will slowly encroach on drm core/helpers,
which is roughly the same as ...

- Throw in the towel on MIT drm core officially. Same as above, except
lets just make it official.

- Try to counter this, which means at least a) relicensing a bunch of
stuff b) rewriting a bunch of stuff c) making sure that's ok with
everyone, there's a lot of GPL-by-default for the kernel (that's how
we got most of the above code through merged drivers I think). I
suspect that whomever cares will need to put in the work to make this
happen (since it will need a pile of active resistance at least).

Cc maintainers/driver teams who might care most about this.

Also if people could cc *bsd, they probably care and I don't know best
contacts for graphics stuff (or anything else really at all).

Cheers, Daniel
-- 
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

[Intel-gfx] [PATCH v2] drm/i915: Flush context free work on cleanup

2019-11-12 Thread Chris Wilson
Throw in a flush_work() to specifically flush the context cleanup work
before the module is unloaded.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112248
Fixes: a4e7ccdac38e ("drm/i915: Move context management under GEM")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 72d389afa28a..17f395672e5e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -776,6 +776,7 @@ int i915_gem_init_contexts(struct drm_i915_private *i915)
 void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
 {
destroy_kernel_context(>kernel_context);
+   flush_work(>gem.contexts.free_work);
 }
 
 static int context_idr_cleanup(int id, void *p, void *data)
-- 
2.24.0

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

Re: [Intel-gfx] [RFC-v2 7/9] drm/i915/dsi: Configure TE interrupt for cmd mode

2019-11-12 Thread Jani Nikula
On Mon, 11 Nov 2019, Vandita Kulkarni  wrote:
> We need to configure TE interrupt in two places.
> Port interrupt and DSI interrupt mask registers.
>
> Signed-off-by: Vandita Kulkarni 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 58 +++--
>  1 file changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index dae00f7dd7df..f27afde409bf 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -41,6 +41,7 @@
>  #include "display/intel_hotplug.h"
>  #include "display/intel_lpe_audio.h"
>  #include "display/intel_psr.h"
> +#include "display/intel_dsi.h"
>  
>  #include "gt/intel_gt.h"
>  #include "gt/intel_gt_irq.h"
> @@ -2571,12 +2572,45 @@ int ilk_enable_vblank(struct drm_crtc *crtc)
>   return 0;
>  }
>  
> +static void gen11_dsi_configure_te(struct drm_i915_private *dev_priv,
> +struct drm_display_mode *mode, bool enable)
> +{
> + enum port port;
> + u32 tmp;
> +
> + if (mode->private_flags & I915_MODE_FLAG_DSI_USE_TE1)
> + port = PORT_B;
> + else
> + port = PORT_A;
> +
> + tmp =  I915_READ(DSI_INTR_MASK_REG(port));
> + if (enable)
> + tmp &= ~DSI_TE_EVENT;
> + else
> + tmp |= DSI_TE_EVENT;
> +
> + I915_WRITE(DSI_INTR_MASK_REG(port), tmp);
> +}
> +
>  int bdw_enable_vblank(struct drm_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> - enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> + struct drm_vblank_crtc *vblank;
> + struct drm_display_mode *mode;
>   unsigned long irqflags;
>  
> + vblank = >dev->vblank[drm_crtc_index(crtc)];
> + mode = >hwmode;
> +
> + if ((INTEL_GEN(dev_priv) >= 11) &&
> + (mode->private_flags &
> +  (I915_MODE_FLAG_DSI_USE_TE1 | I915_MODE_FLAG_DSI_USE_TE0))) {
> + gen11_dsi_configure_te(dev_priv, mode, true);
> + return 0;
> + }
> +

I'd hide this more inside gen11_dsi_configure_te():

if (gen11_dsi_configure_te(crtc))
return 0;

and make that function early return false if neither TE flag is set. It
also doesn't have to check for gen, because you can trust those flags
are only set where it matters.

>   spin_lock_irqsave(_priv->irq_lock, irqflags);
>   bdw_enable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> @@ -2642,9 +2676,22 @@ void ilk_disable_vblank(struct drm_crtc *crtc)
>  void bdw_disable_vblank(struct drm_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> - enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> + struct drm_vblank_crtc *vblank;
> + struct drm_display_mode *mode;
>   unsigned long irqflags;
>  
> + vblank = >dev->vblank[drm_crtc_index(crtc)];
> + mode = >hwmode;
> +
> + if ((INTEL_GEN(dev_priv) >= 11) &&
> + (mode->private_flags &
> +  (I915_MODE_FLAG_DSI_USE_TE1 | I915_MODE_FLAG_DSI_USE_TE0))) {
> + gen11_dsi_configure_te(dev_priv, mode, false);
> + return;
> + }
> +

Ditto, keep this function clean.

>   spin_lock_irqsave(_priv->irq_lock, irqflags);
>   bdw_disable_pipe_irq(dev_priv, pipe, GEN8_PIPE_VBLANK);
>   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> @@ -3350,6 +3397,13 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   gen3_assert_iir_is_zero(uncore, EDP_PSR_IIR);
>   }
>  
> + if (INTEL_GEN(dev_priv) >= 11) {
> + enum port port;
> +
> + if (intel_bios_is_dsi_present(dev_priv, ))
> + de_port_masked |= DSI0_TE | DSI1_TE;
> + }
> +

Not really happy about this one, but perhaps acceptable for now.

BR,
Jani.

>   for_each_pipe(dev_priv, pipe) {
>   dev_priv->de_irq_mask[pipe] = ~de_pipe_masked;

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

Re: [Intel-gfx] [PATCH 01/27] drm/i915: Flush context free work on cleanup

2019-11-12 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-12 14:23:14)
> Chris Wilson  writes:
> 
> > Throw in a flush_work() and rcu_barrier() to specifically flush the
> > context cleanup work.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112248
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
> >  drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 1 +
> >  2 files changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 72d389afa28a..17f395672e5e 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -776,6 +776,7 @@ int i915_gem_init_contexts(struct drm_i915_private 
> > *i915)
> >  void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
> >  {
> >   destroy_kernel_context(>kernel_context);
> > + flush_work(>gem.contexts.free_work);
> >  }
> >  
> >  static int context_idr_cleanup(int id, void *p, void *data)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index b9613d044393..1f68700a2311 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -402,6 +402,7 @@ void intel_engines_cleanup(struct intel_gt *gt)
> >   gt->engine[id] = NULL;
> >   gt->i915->engine[id] = NULL;
> >   }
> > + rcu_barrier();
> 
> I guess we need this for releasing kernel_ctx but I don't see why
> exactly.

It's the rcu'ed ppgtt I worry about.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 24/27] drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all others

2019-11-12 Thread Chris Wilson
Quoting Mika Kuoppala (2019-11-12 14:13:56)
> Chris Wilson  writes:
> 
> > Be consistent in our mocs setup on Tigerlake and set the unused control
> > value to follow the PTE entry as we previously have done. The unused
> > values are beyond the defines of the ABI, the consistency simplifies our
> > checking.
> 
> Simplifies how?

Because all platforms follow the same pattern, we only need one routine
not multiples.

> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > index 6e881c735b20..d2b445d6c258 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > @@ -489,7 +489,7 @@ static void intel_mocs_init_global(struct intel_gt *gt)
> >   for (; index < table.n_entries; index++)
> >   intel_uncore_write(uncore,
> >  GEN12_GLOBAL_MOCS(index),
> > -table.table[0].control_value);
> > +table.table[I915_MOCS_PTE].control_value);
> 
> This sets it point into reserved, so I am confused.

Outside of the ABI.

> Also the comment above and the part in generic MOCS tables will
> be stale.

Look at the next pair of patches for removing most of the file, now
possible because the dissimilarity is removed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/bios: change slice count check

2019-11-12 Thread Jani Nikula
FIXME: fixup to original.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_bios.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 522c399753fe..cdd30eeda7be 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2260,11 +2260,9 @@ static void fill_dsc(struct intel_crtc_state 
*pipe_config,
 *
 * Also, per spec DSI supports 1, 2, 3 or 4 horizontal slices.
 */
-   if (dsc->slices_per_line & BIT(2) &&
-   pipe_config->hw.adjusted_mode.crtc_hdisplay % 4 == 0) {
+   if (dsc->slices_per_line & BIT(2)) {
pipe_config->dsc.slice_count = 4;
-   } else if (dsc->slices_per_line & BIT(1) &&
-  pipe_config->hw.adjusted_mode.crtc_hdisplay % 2 == 0) {
+   } else if (dsc->slices_per_line & BIT(1)) {
pipe_config->dsc.slice_count = 2;
} else {
/* FIXME */
@@ -2274,6 +2272,12 @@ static void fill_dsc(struct intel_crtc_state 
*pipe_config,
pipe_config->dsc.slice_count = 1;
}
 
+   if (pipe_config->hw.adjusted_mode.crtc_hdisplay %
+   pipe_config->dsc.slice_count != 0)
+   DRM_DEBUG_KMS("DSC hdisplay %d not divisible by slice count 
%d\n",
+ pipe_config->hw.adjusted_mode.crtc_hdisplay,
+ pipe_config->dsc.slice_count);
+
/* FIXME: rc_buffer_block_size, using defaults in intel_vdsc.c */
 
/* FIXME: rc_buffer_size, using defaults in intel_vdsc.c */
-- 
2.20.1

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

[Intel-gfx] [PATCH 1/2] drm/i915: Explicitly cleanup initial_plane_config

2019-11-12 Thread Chris Wilson
I am about to stuff more objects into the plane_config and would like to
have it clean up after itself. Move the current framebuffer release into
a common function so it can be extended with the new object with
relative ease.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5f3340554149..f571c6575c62 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3241,8 +3241,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
goto valid_fb;
}
 
-   kfree(plane_config->fb);
-
/*
 * Failed to alloc the obj, check to see if we should share
 * an fb with another CRTC instead
@@ -3262,7 +3260,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
 
if (intel_plane_ggtt_offset(state) == plane_config->base) {
fb = state->hw.fb;
-   drm_framebuffer_get(fb);
goto valid_fb;
}
}
@@ -3295,7 +3292,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
  intel_crtc->pipe, PTR_ERR(intel_state->vma));
 
intel_state->vma = NULL;
-   drm_framebuffer_put(fb);
return;
}
 
@@ -3317,7 +3313,6 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
if (plane_config->tiling)
dev_priv->preserve_bios_swizzle = true;
 
-   plane_state->fb = fb;
plane_state->crtc = _crtc->base;
intel_plane_copy_uapi_to_hw_state(intel_state, intel_state);
 
@@ -16952,6 +16947,19 @@ static void intel_mode_config_init(struct 
drm_i915_private *i915)
}
 }
 
+static void plane_config_fini(struct intel_initial_plane_config *plane_config)
+{
+   if (plane_config->fb) {
+   struct drm_framebuffer *fb = _config->fb->base;
+
+   /* We may only have the stub and not a full framebuffer */
+   if (drm_framebuffer_read_refcount(fb))
+   drm_framebuffer_put(fb);
+   else
+   kfree(fb);
+   }
+}
+
 int intel_modeset_init(struct drm_i915_private *i915)
 {
struct drm_device *dev = >drm;
@@ -17036,6 +17044,8 @@ int intel_modeset_init(struct drm_i915_private *i915)
 * just get the first one.
 */
intel_find_initial_plane_obj(crtc, _config);
+
+   plane_config_fini(_config);
}
 
/*
-- 
2.24.0

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

[Intel-gfx] [PATCH 2/2] drm/i915/display: Be explicit in handling the preallocated vma

2019-11-12 Thread Chris Wilson
As only the display codes tries to pin its preallocated framebuffer into
an exact location in the GGTT, remove the convenience function and make
the pin management explicit in the display code. Then throughout the
display management, we track the framebuffer and its plane->vma; with
less single purpose code and ready for first class i915_vma.

In doing so, this should fix the BUG_ON(vma->pages) on fi-kbl-soraka.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/display/intel_display.c  | 141 +++---
 .../drm/i915/display/intel_display_types.h|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  80 ++
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|   1 -
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   1 -
 5 files changed, 102 insertions(+), 122 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f571c6575c62..fc823bbfe481 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3083,6 +3083,69 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
}
 }
 
+static struct i915_vma *
+initial_plane_vma(struct drm_i915_private *i915,
+ struct intel_initial_plane_config *plane_config)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   u32 base, size;
+   int err;
+
+   if (plane_config->size == 0)
+   return NULL;
+
+   base = round_down(plane_config->base, PAGE_SIZE);
+   size = round_up(plane_config->base + plane_config->size, PAGE_SIZE);
+   size -= base;
+
+   /*
+* If the FB is too big, just don't use it since fbdev is not very
+* important and we should probably use that space with FBC or other
+* features.
+*/
+   if (size * 2 > i915->stolen_usable_size)
+   return NULL;
+
+   obj = i915_gem_object_create_stolen_for_preallocated(i915, base, size);
+   if (!obj)
+   return NULL;
+
+   switch (plane_config->tiling) {
+   case I915_TILING_NONE:
+   break;
+   case I915_TILING_X:
+   case I915_TILING_Y:
+   obj->tiling_and_stride =
+   plane_config->fb->base.pitches[0] |
+   plane_config->tiling;
+   break;
+   default:
+   MISSING_CASE(plane_config->tiling);
+   goto err_obj;
+   }
+
+   vma = i915_vma_instance(obj, >ggtt.vm, NULL);
+   if (IS_ERR(vma))
+   goto err_obj;
+
+   err = i915_vma_pin(vma, 0, 0,
+  PIN_GLOBAL | PIN_MAPPABLE |
+  base | PIN_OFFSET_FIXED);
+   if (err)
+   goto err_obj;
+
+   if (i915_gem_object_is_tiled(obj) &&
+   !i915_vma_is_map_and_fenceable(vma))
+   goto err_obj;
+
+   return vma;
+
+err_obj:
+   i915_gem_object_put(obj);
+   return NULL;
+}
+
 static bool
 intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
  struct intel_initial_plane_config *plane_config)
@@ -3091,22 +3154,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
struct drm_framebuffer *fb = _config->fb->base;
-   u32 base_aligned = round_down(plane_config->base, PAGE_SIZE);
-   u32 size_aligned = round_up(plane_config->base + plane_config->size,
-   PAGE_SIZE);
-   struct drm_i915_gem_object *obj;
-   bool ret = false;
-
-   size_aligned -= base_aligned;
-
-   if (plane_config->size == 0)
-   return false;
-
-   /* If the FB is too big, just don't use it since fbdev is not very
-* important and we should probably use that space with FBC or other
-* features. */
-   if (size_aligned * 2 > dev_priv->stolen_usable_size)
-   return false;
+   struct i915_vma *vma;
 
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
@@ -3119,25 +3167,10 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
return false;
}
 
-   obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
-base_aligned,
-base_aligned,
-size_aligned);
-   if (IS_ERR(obj))
+   vma = initial_plane_vma(dev_priv, plane_config);
+   if (!vma)
return false;
 
-   switch (plane_config->tiling) {
-   case I915_TILING_NONE:
-   break;
-   case I915_TILING_X:
-   case I915_TILING_Y:
-   obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
-   break;
-   default:
-   

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Flush context free work on cleanup

2019-11-12 Thread Patchwork
== Series Details ==

Series: drm/i915: Flush context free work on cleanup
URL   : https://patchwork.freedesktop.org/series/69339/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7312_full -> Patchwork_15228_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_15228_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_15228_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_15228_full:

### IGT changes ###

 Possible regressions 

  * igt@prime_self_import@basic-llseek-size:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb7/igt@prime_self_imp...@basic-llseek-size.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-tglb9/igt@prime_self_imp...@basic-llseek-size.html

  
Known issues


  Here are the changes found in Patchwork_15228_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@vcs1-queued:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) 
+1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb1/igt@gem_ctx_persiste...@vcs1-queued.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-iclb7/igt@gem_ctx_persiste...@vcs1-queued.html

  * igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html

  * igt@gem_exec_async@concurrent-writes-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +6 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb8/igt@gem_exec_as...@concurrent-writes-bsd.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html

  * igt@gem_exec_schedule@independent-bsd1:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +7 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb4/igt@gem_exec_sched...@independent-bsd1.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-iclb3/igt@gem_exec_sched...@independent-bsd1.html

  * igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#112037])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb8/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-iclb8/igt@gem_persistent_rel...@forked-interruptible-thrashing.html

  * igt@gem_sync@basic-each:
- shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([fdo#111647] / 
[fdo#111998])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb1/igt@gem_s...@basic-each.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-tglb6/igt@gem_s...@basic-each.html

  * igt@gem_userptr_blits@sync-unmap-after-close:
- shard-hsw:  [PASS][15] -> [DMESG-WARN][16] ([fdo#111870])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-hsw5/igt@gem_userptr_bl...@sync-unmap-after-close.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-hsw6/igt@gem_userptr_bl...@sync-unmap-after-close.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-kbl:  [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +3 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html

  * igt@i915_pm_backlight@fade_with_suspend:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111832] / 
[fdo#111850]) +3 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-tglb2/igt@i915_pm_backlight@fade_with_suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15228/shard-tglb7/igt@i915_pm_backlight@fade_with_suspend.html

  * igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#111795 ])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7312/shard-iclb5/igt@i915_pm...@dc5-dpms.html
   [22]: 

Re: [Intel-gfx] [PATCH 01/27] drm/i915: Flush context free work on cleanup

2019-11-12 Thread Mika Kuoppala
Chris Wilson  writes:

> Throw in a flush_work() and rcu_barrier() to specifically flush the
> context cleanup work.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112248
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 72d389afa28a..17f395672e5e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -776,6 +776,7 @@ int i915_gem_init_contexts(struct drm_i915_private *i915)
>  void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
>  {
>   destroy_kernel_context(>kernel_context);
> + flush_work(>gem.contexts.free_work);
>  }
>  
>  static int context_idr_cleanup(int id, void *p, void *data)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index b9613d044393..1f68700a2311 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -402,6 +402,7 @@ void intel_engines_cleanup(struct intel_gt *gt)
>   gt->engine[id] = NULL;
>   gt->i915->engine[id] = NULL;
>   }
> + rcu_barrier();

I guess we need this for releasing kernel_ctx but I don't see why
exactly.
-Mika


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

[Intel-gfx] [PATCH 09/10] drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Rename pipe_config to new_crtc_state in the .crtc_enable() hooks.
The 'pipe_config' name is a zombie that we need to finally put down.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 175 +--
 1 file changed, 86 insertions(+), 89 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index b091b92a677c..11953fe06488 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6460,10 +6460,10 @@ static void intel_disable_primary_plane(const struct 
intel_crtc_state *crtc_stat
plane->disable_plane(plane, crtc_state);
 }
 
-static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config,
+static void ironlake_crtc_enable(struct intel_crtc_state *new_crtc_state,
 struct intel_atomic_state *state)
 {
-   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
+   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
@@ -6483,55 +6483,54 @@ static void ironlake_crtc_enable(struct 
intel_crtc_state *pipe_config,
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, false);
 
-   if (pipe_config->has_pch_encoder)
-   intel_prepare_shared_dpll(pipe_config);
+   if (new_crtc_state->has_pch_encoder)
+   intel_prepare_shared_dpll(new_crtc_state);
 
-   if (intel_crtc_has_dp_encoder(pipe_config))
-   intel_dp_set_m_n(pipe_config, M1_N1);
+   if (intel_crtc_has_dp_encoder(new_crtc_state))
+   intel_dp_set_m_n(new_crtc_state, M1_N1);
 
-   intel_set_pipe_timings(pipe_config);
-   intel_set_pipe_src_size(pipe_config);
+   intel_set_pipe_timings(new_crtc_state);
+   intel_set_pipe_src_size(new_crtc_state);
 
-   if (pipe_config->has_pch_encoder) {
-   intel_cpu_transcoder_set_m_n(pipe_config,
-_config->fdi_m_n, NULL);
-   }
+   if (new_crtc_state->has_pch_encoder)
+   intel_cpu_transcoder_set_m_n(new_crtc_state,
+_crtc_state->fdi_m_n, NULL);
 
-   ironlake_set_pipeconf(pipe_config);
+   ironlake_set_pipeconf(new_crtc_state);
 
crtc->active = true;
 
intel_encoders_pre_enable(state, crtc);
 
-   if (pipe_config->has_pch_encoder) {
+   if (new_crtc_state->has_pch_encoder) {
/* Note: FDI PLL enabling _must_ be done before we enable the
 * cpu pipes, hence this is separate from all the other fdi/pch
 * enabling. */
-   ironlake_fdi_pll_enable(pipe_config);
+   ironlake_fdi_pll_enable(new_crtc_state);
} else {
assert_fdi_tx_disabled(dev_priv, pipe);
assert_fdi_rx_disabled(dev_priv, pipe);
}
 
-   ironlake_pfit_enable(pipe_config);
+   ironlake_pfit_enable(new_crtc_state);
 
/*
 * On ILK+ LUT must be loaded before the pipe is running but with
 * clocks enabled
 */
-   intel_color_load_luts(pipe_config);
-   intel_color_commit(pipe_config);
+   intel_color_load_luts(new_crtc_state);
+   intel_color_commit(new_crtc_state);
/* update DSPCNTR to configure gamma for pipe bottom color */
-   intel_disable_primary_plane(pipe_config);
+   intel_disable_primary_plane(new_crtc_state);
 
if (dev_priv->display.initial_watermarks)
dev_priv->display.initial_watermarks(state, crtc);
-   intel_enable_pipe(pipe_config);
+   intel_enable_pipe(new_crtc_state);
 
-   if (pipe_config->has_pch_encoder)
-   ironlake_pch_enable(state, pipe_config);
+   if (new_crtc_state->has_pch_encoder)
+   ironlake_pch_enable(state, new_crtc_state);
 
-   intel_crtc_vblank_on(pipe_config);
+   intel_crtc_vblank_on(new_crtc_state);
 
intel_encoders_enable(state, crtc);
 
@@ -6544,7 +6543,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
 * some interlaced HDMI modes. Let's do the double wait always
 * in case there are more corner cases we don't know about.
 */
-   if (pipe_config->has_pch_encoder) {
+   if (new_crtc_state->has_pch_encoder) {
intel_wait_for_vblank(dev_priv, pipe);
intel_wait_for_vblank(dev_priv, pipe);
}
@@ -6591,13 +6590,13 @@ static void icl_pipe_mbus_enable(struct intel_crtc 
*crtc)
I915_WRITE(PIPE_MBUS_DBOX_CTL(pipe), val);
 }
 
-static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
+static void haswell_crtc_enable(struct intel_crtc_state *new_crtc_state,

[Intel-gfx] [PATCH 08/10] drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Get rid of the horrible aliasing drm_crtc and intel_crtc variables
in the crtc enable/disable hooks.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 142 +--
 1 file changed, 65 insertions(+), 77 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 6afdbfbb3264..b091b92a677c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6463,13 +6463,11 @@ static void intel_disable_primary_plane(const struct 
intel_crtc_state *crtc_stat
 static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config,
 struct intel_atomic_state *state)
 {
-   struct drm_crtc *crtc = pipe_config->uapi.crtc;
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
+   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
 
-   if (WARN_ON(intel_crtc->active))
+   if (WARN_ON(crtc->active))
return;
 
/*
@@ -6501,9 +6499,9 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
 
ironlake_set_pipeconf(pipe_config);
 
-   intel_crtc->active = true;
+   crtc->active = true;
 
-   intel_encoders_pre_enable(state, intel_crtc);
+   intel_encoders_pre_enable(state, crtc);
 
if (pipe_config->has_pch_encoder) {
/* Note: FDI PLL enabling _must_ be done before we enable the
@@ -6527,7 +6525,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_disable_primary_plane(pipe_config);
 
if (dev_priv->display.initial_watermarks)
-   dev_priv->display.initial_watermarks(state, intel_crtc);
+   dev_priv->display.initial_watermarks(state, crtc);
intel_enable_pipe(pipe_config);
 
if (pipe_config->has_pch_encoder)
@@ -6535,7 +6533,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
 
intel_crtc_vblank_on(pipe_config);
 
-   intel_encoders_enable(state, intel_crtc);
+   intel_encoders_enable(state, crtc);
 
if (HAS_PCH_CPT(dev_priv))
cpt_verify_modeset(dev_priv, pipe);
@@ -6596,22 +6594,21 @@ static void icl_pipe_mbus_enable(struct intel_crtc 
*crtc)
 static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
struct intel_atomic_state *state)
 {
-   struct drm_crtc *crtc = pipe_config->uapi.crtc;
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe, hsw_workaround_pipe;
+   struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
bool psl_clkgate_wa;
 
-   if (WARN_ON(intel_crtc->active))
+   if (WARN_ON(crtc->active))
return;
 
-   intel_encoders_pre_pll_enable(state, intel_crtc);
+   intel_encoders_pre_pll_enable(state, crtc);
 
if (pipe_config->shared_dpll)
intel_enable_shared_dpll(pipe_config);
 
-   intel_encoders_pre_enable(state, intel_crtc);
+   intel_encoders_pre_enable(state, crtc);
 
if (intel_crtc_has_dp_encoder(pipe_config))
intel_dp_set_m_n(pipe_config, M1_N1);
@@ -6641,7 +6638,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
bdw_set_pipemisc(pipe_config);
 
-   intel_crtc->active = true;
+   crtc->active = true;
 
/* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
@@ -6665,16 +6662,16 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_disable_primary_plane(pipe_config);
 
if (INTEL_GEN(dev_priv) >= 11)
-   icl_set_pipe_chicken(intel_crtc);
+   icl_set_pipe_chicken(crtc);
 
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_transcoder_func(pipe_config);
 
if (dev_priv->display.initial_watermarks)
-   dev_priv->display.initial_watermarks(state, intel_crtc);
+   dev_priv->display.initial_watermarks(state, crtc);
 
if (INTEL_GEN(dev_priv) >= 11)
-   icl_pipe_mbus_enable(intel_crtc);
+   icl_pipe_mbus_enable(crtc);
 
/* XXX: Do the pipe assertions at the 

[Intel-gfx] [PATCH 00/10] drm/i915: Cleanups around .crtc_enable/disable()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

My eyes have been bleeding long enough. Let's try to clean up some of
this mess.

Ville Syrjälä (10):
  drm/i915: Change intel_encoders_() calling convention
  drm/i915: Add intel_crtc_vblank_off()
  drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on()
  drm/i915: Move crtc_state to tighter scope
  drm/i915: Pass intel_crtc to ironlake_fdi_disable()
  drm/i915: Change watermark hook calling convention
  drm/i915: Pass dev_priv to cpt_verify_modeset()
  drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable()
  drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable()
  drm/i915: Change .crtc_enable/disable() calling convention

 drivers/gpu/drm/i915/display/intel_display.c | 461 +--
 drivers/gpu/drm/i915/i915_drv.h  |  14 +-
 drivers/gpu/drm/i915/intel_pm.c  |  63 +--
 3 files changed, 272 insertions(+), 266 deletions(-)

-- 
2.23.0

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

[Intel-gfx] [PATCH 03/10] drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Move the assert_vblank_disabled() into intel_crtc_vblank_on()
so that we don't have to inline it all over.

This does mean we now assert_vblank_disabled() during readout as well
but that is totally fine as it happens after drm_crtc_vblank_reset().
One can even argue it's what we want to do anyway to make sure
the reset actually happened.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 194029ff8617..89d150b45520 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1826,6 +1826,7 @@ static void intel_crtc_vblank_on(const struct 
intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
 
+   assert_vblank_disabled(>base);
drm_crtc_set_max_vblank_count(>base,
  intel_crtc_max_vblank_count(crtc_state));
drm_crtc_vblank_on(>base);
@@ -6535,7 +6536,6 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (pipe_config->has_pch_encoder)
ironlake_pch_enable(state, pipe_config);
 
-   assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
 
intel_encoders_enable(state, intel_crtc);
@@ -6689,7 +6689,6 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(pipe_config, true);
 
-   assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
 
intel_encoders_enable(state, intel_crtc);
@@ -7068,7 +7067,6 @@ static void valleyview_crtc_enable(struct 
intel_crtc_state *pipe_config,
dev_priv->display.initial_watermarks(state, pipe_config);
intel_enable_pipe(pipe_config);
 
-   assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
 
intel_encoders_enable(state, intel_crtc);
@@ -7128,7 +7126,6 @@ static void i9xx_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_update_watermarks(intel_crtc);
intel_enable_pipe(pipe_config);
 
-   assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
 
intel_encoders_enable(state, intel_crtc);
-- 
2.23.0

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

[Intel-gfx] [PATCH 06/10] drm/i915: Change watermark hook calling convention

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Just pass the atomic_state+crtc to the watermarks hooks. Eeasier
time for the caller when it doesn't have to think what to pass.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 32 +-
 drivers/gpu/drm/i915/i915_drv.h  |  6 +-
 drivers/gpu/drm/i915/intel_pm.c  | 63 +++-
 3 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index ffadfd90c3cf..77b739cda053 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6177,9 +6177,8 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state,
 * we'll continue to update watermarks the old way, if flags tell
 * us to.
 */
-   if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(intel_state,
-pipe_config);
+   if (dev_priv->display.initial_watermarks)
+   dev_priv->display.initial_watermarks(intel_state, crtc);
else if (pipe_config->update_wm_pre)
intel_update_watermarks(crtc);
 }
@@ -6527,8 +6526,8 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
/* update DSPCNTR to configure gamma for pipe bottom color */
intel_disable_primary_plane(pipe_config);
 
-   if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(state, pipe_config);
+   if (dev_priv->display.initial_watermarks)
+   dev_priv->display.initial_watermarks(state, intel_crtc);
intel_enable_pipe(pipe_config);
 
if (pipe_config->has_pch_encoder)
@@ -6671,8 +6670,8 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_transcoder_func(pipe_config);
 
-   if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(state, pipe_config);
+   if (dev_priv->display.initial_watermarks)
+   dev_priv->display.initial_watermarks(state, intel_crtc);
 
if (INTEL_GEN(dev_priv) >= 11)
icl_pipe_mbus_enable(intel_crtc);
@@ -7062,7 +7061,7 @@ static void valleyview_crtc_enable(struct 
intel_crtc_state *pipe_config,
/* update DSPCNTR to configure gamma for pipe bottom color */
intel_disable_primary_plane(pipe_config);
 
-   dev_priv->display.initial_watermarks(state, pipe_config);
+   dev_priv->display.initial_watermarks(state, intel_crtc);
intel_enable_pipe(pipe_config);
 
intel_crtc_vblank_on(pipe_config);
@@ -7117,9 +7116,8 @@ static void i9xx_crtc_enable(struct intel_crtc_state 
*pipe_config,
/* update DSPCNTR to configure gamma for pipe bottom color */
intel_disable_primary_plane(pipe_config);
 
-   if (dev_priv->display.initial_watermarks != NULL)
-   dev_priv->display.initial_watermarks(state,
-pipe_config);
+   if (dev_priv->display.initial_watermarks)
+   dev_priv->display.initial_watermarks(state, intel_crtc);
else
intel_update_watermarks(intel_crtc);
intel_enable_pipe(pipe_config);
@@ -14291,6 +14289,7 @@ static void commit_pipe_config(struct 
intel_atomic_state *state,
   struct intel_crtc_state *old_crtc_state,
   struct intel_crtc_state *new_crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
bool modeset = needs_modeset(new_crtc_state);
 
@@ -14314,8 +14313,7 @@ static void commit_pipe_config(struct 
intel_atomic_state *state,
}
 
if (dev_priv->display.atomic_update_watermarks)
-   dev_priv->display.atomic_update_watermarks(state,
-  new_crtc_state);
+   dev_priv->display.atomic_update_watermarks(state, crtc);
 }
 
 static void intel_update_crtc(struct intel_crtc *crtc,
@@ -14419,8 +14417,7 @@ static void intel_old_crtc_state_disables(struct 
intel_atomic_state *state,
if (!new_crtc_state->hw.active &&
!HAS_GMCH(dev_priv) &&
dev_priv->display.initial_watermarks)
-   dev_priv->display.initial_watermarks(state,
-new_crtc_state);
+   dev_priv->display.initial_watermarks(state, crtc);
 }
 
 static void intel_trans_port_sync_modeset_disables(struct intel_atomic_state 
*state,
@@ -14870,8 +14867,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
 */

[Intel-gfx] [PATCH 07/10] drm/i915: Pass dev_priv to cpt_verify_modeset()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Get rid of the last 'dev' usage in ironlake_crtc_enable() by
passing dev_priv to cpt_verify_modeset().

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 77b739cda053..6afdbfbb3264 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5462,9 +5462,9 @@ static void lpt_pch_enable(const struct 
intel_atomic_state *state,
lpt_enable_pch_transcoder(dev_priv, cpu_transcoder);
 }
 
-static void cpt_verify_modeset(struct drm_device *dev, enum pipe pipe)
+static void cpt_verify_modeset(struct drm_i915_private *dev_priv,
+  enum pipe pipe)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t dslreg = PIPEDSL(pipe);
u32 temp;
 
@@ -6538,7 +6538,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_encoders_enable(state, intel_crtc);
 
if (HAS_PCH_CPT(dev_priv))
-   cpt_verify_modeset(dev, intel_crtc->pipe);
+   cpt_verify_modeset(dev_priv, pipe);
 
/*
 * Must wait for vblank to avoid spurious PCH FIFO underruns.
-- 
2.23.0

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

[Intel-gfx] [PATCH 02/10] drm/i915: Add intel_crtc_vblank_off()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

We already have intel_crtc_vblank_on(). Add a counterpart so we
don't have to inline the disable+assert all over.

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

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index da01fa6928a2..194029ff8617 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1831,6 +1831,12 @@ static void intel_crtc_vblank_on(const struct 
intel_crtc_state *crtc_state)
drm_crtc_vblank_on(>base);
 }
 
+static void intel_crtc_vblank_off(struct intel_crtc *crtc)
+{
+   drm_crtc_vblank_off(>base);
+   assert_vblank_disabled(>base);
+}
+
 static void intel_enable_pipe(const struct intel_crtc_state *new_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
@@ -6736,8 +6742,7 @@ static void ironlake_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
 
intel_encoders_disable(state, intel_crtc);
 
-   drm_crtc_vblank_off(crtc);
-   assert_vblank_disabled(crtc);
+   intel_crtc_vblank_off(intel_crtc);
 
intel_disable_pipe(old_crtc_state);
 
@@ -6786,8 +6791,7 @@ static void haswell_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
 
intel_encoders_disable(state, intel_crtc);
 
-   drm_crtc_vblank_off(crtc);
-   assert_vblank_disabled(crtc);
+   intel_crtc_vblank_off(intel_crtc);
 
/* XXX: Do the pipe assertions at the right place for BXT DSI. */
if (!transcoder_is_dsi(cpu_transcoder))
@@ -7163,8 +7167,7 @@ static void i9xx_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
 
intel_encoders_disable(state, intel_crtc);
 
-   drm_crtc_vblank_off(crtc);
-   assert_vblank_disabled(crtc);
+   intel_crtc_vblank_off(intel_crtc);
 
intel_disable_pipe(old_crtc_state);
 
-- 
2.23.0

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

[Intel-gfx] [PATCH 10/10] drm/i915: Change .crtc_enable/disable() calling convention

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Just pass the atomic state+crtc to the .crtc_enable()
.crtc_disable(). Life is easier when you don't have to think
whether to pass the old or the new crtc state.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 58 +++-
 drivers/gpu/drm/i915/i915_drv.h  |  8 +--
 2 files changed, 37 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 11953fe06488..96eafd51296c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6460,10 +6460,11 @@ static void intel_disable_primary_plane(const struct 
intel_crtc_state *crtc_stat
plane->disable_plane(plane, crtc_state);
 }
 
-static void ironlake_crtc_enable(struct intel_crtc_state *new_crtc_state,
-struct intel_atomic_state *state)
+static void ironlake_crtc_enable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+   const struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
@@ -6590,10 +6591,11 @@ static void icl_pipe_mbus_enable(struct intel_crtc 
*crtc)
I915_WRITE(PIPE_MBUS_DBOX_CTL(pipe), val);
 }
 
-static void haswell_crtc_enable(struct intel_crtc_state *new_crtc_state,
-   struct intel_atomic_state *state)
+static void haswell_crtc_enable(struct intel_atomic_state *state,
+   struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+   const struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
@@ -6713,10 +6715,11 @@ static void ironlake_pfit_disable(const struct 
intel_crtc_state *old_crtc_state)
}
 }
 
-static void ironlake_crtc_disable(struct intel_crtc_state *old_crtc_state,
- struct intel_atomic_state *state)
+static void ironlake_crtc_disable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
+   const struct intel_crtc_state *old_crtc_state =
+   intel_atomic_get_old_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
@@ -6769,10 +6772,11 @@ static void ironlake_crtc_disable(struct 
intel_crtc_state *old_crtc_state,
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);
 }
 
-static void haswell_crtc_disable(struct intel_crtc_state *old_crtc_state,
-struct intel_atomic_state *state)
+static void haswell_crtc_disable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
+   const struct intel_crtc_state *old_crtc_state =
+   intel_atomic_get_old_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
 
@@ -7004,10 +7008,11 @@ static void modeset_put_power_domains(struct 
drm_i915_private *dev_priv,
intel_display_power_put_unchecked(dev_priv, domain);
 }
 
-static void valleyview_crtc_enable(struct intel_crtc_state *new_crtc_state,
-  struct intel_atomic_state *state)
+static void valleyview_crtc_enable(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+   const struct intel_crtc_state *new_crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
 
@@ -7067,10 +7072,11 @@ static void i9xx_set_pll_dividers(const struct 
intel_crtc_state *crtc_state)
I915_WRITE(FP1(crtc->pipe), crtc_state->dpll_hw_state.fp1);
 }
 
-static void i9xx_crtc_enable(struct intel_crtc_state *new_crtc_state,
-struct intel_atomic_state *state)
+static void i9xx_crtc_enable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
 {
-   struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+   const struct intel_crtc_state *new_crtc_state =
+   

[Intel-gfx] [PATCH 05/10] drm/i915: Pass intel_crtc to ironlake_fdi_disable()

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Switch to intel_crtc from drm_crtc.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index e52ea9643790..ffadfd90c3cf 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5049,12 +5049,10 @@ static void ironlake_fdi_pll_disable(struct intel_crtc 
*intel_crtc)
udelay(100);
 }
 
-static void ironlake_fdi_disable(struct drm_crtc *crtc)
+static void ironlake_fdi_disable(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum pipe pipe = intel_crtc->pipe;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 temp;
 
@@ -6748,7 +6746,7 @@ static void ironlake_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
ironlake_pfit_disable(old_crtc_state);
 
if (old_crtc_state->has_pch_encoder)
-   ironlake_fdi_disable(crtc);
+   ironlake_fdi_disable(intel_crtc);
 
intel_encoders_post_disable(state, intel_crtc);
 
-- 
2.23.0

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

[Intel-gfx] [PATCH 04/10] drm/i915: Move crtc_state to tighter scope

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

intel_modeset_setup_hw_state() doesn't need the crtc_state at the
top level scope. Move it to where it's needed.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 89d150b45520..e52ea9643790 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17716,7 +17716,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
 struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc_state *crtc_state;
struct intel_encoder *encoder;
struct intel_crtc *crtc;
intel_wakeref_t wakeref;
@@ -17749,7 +17748,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
 * waits, so we need vblank interrupts restored beforehand.
 */
for_each_intel_crtc(_priv->drm, crtc) {
-   crtc_state = to_intel_crtc_state(crtc->base.state);
+   struct intel_crtc_state *crtc_state =
+   to_intel_crtc_state(crtc->base.state);
 
drm_crtc_vblank_reset(>base);
 
@@ -17763,7 +17763,9 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
intel_sanitize_encoder(encoder);
 
for_each_intel_crtc(_priv->drm, crtc) {
-   crtc_state = to_intel_crtc_state(crtc->base.state);
+   struct intel_crtc_state *crtc_state =
+   crtc_state = to_intel_crtc_state(crtc->base.state);
+
intel_sanitize_crtc(crtc, ctx);
intel_dump_pipe_config(crtc_state, NULL, "[setup_hw_state]");
}
@@ -17796,9 +17798,10 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
}
 
for_each_intel_crtc(dev, crtc) {
+   struct intel_crtc_state *crtc_state =
+   to_intel_crtc_state(crtc->base.state);
u64 put_domains;
 
-   crtc_state = to_intel_crtc_state(crtc->base.state);
put_domains = modeset_get_crtc_power_domains(crtc_state);
if (WARN_ON(put_domains))
modeset_put_power_domains(dev_priv, put_domains);
-- 
2.23.0

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

[Intel-gfx] [PATCH 01/10] drm/i915: Change intel_encoders_() calling convention

2019-11-12 Thread Ville Syrjala
From: Ville Syrjälä 

Just pass the atomic state and the crtc to intel_encoders_enable() & co.
Make life simpler when you don't have to think which state (old vs. new)
you have to pass in. Also constify the states while at it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/display/intel_display.c | 101 ++-
 1 file changed, 54 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 5f3340554149..da01fa6928a2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6299,11 +6299,12 @@ static void intel_encoders_update_complete(struct 
intel_atomic_state *state)
}
 }
 
-static void intel_encoders_pre_pll_enable(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_pre_pll_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
 {
-   struct drm_connector_state *conn_state;
+   const struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   const struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
@@ -6319,11 +6320,12 @@ static void intel_encoders_pre_pll_enable(struct 
intel_crtc *crtc,
}
 }
 
-static void intel_encoders_pre_enable(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_pre_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
 {
-   struct drm_connector_state *conn_state;
+   const struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   const struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
@@ -6339,11 +6341,12 @@ static void intel_encoders_pre_enable(struct intel_crtc 
*crtc,
}
 }
 
-static void intel_encoders_enable(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
 {
-   struct drm_connector_state *conn_state;
+   const struct intel_crtc_state *crtc_state =
+   intel_atomic_get_new_crtc_state(state, crtc);
+   const struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
@@ -6360,11 +6363,12 @@ static void intel_encoders_enable(struct intel_crtc 
*crtc,
}
 }
 
-static void intel_encoders_disable(struct intel_crtc *crtc,
-  struct intel_crtc_state *old_crtc_state,
-  struct intel_atomic_state *state)
+static void intel_encoders_disable(struct intel_atomic_state *state,
+  struct intel_crtc *crtc)
 {
-   struct drm_connector_state *old_conn_state;
+   const struct intel_crtc_state *old_crtc_state =
+   intel_atomic_get_old_crtc_state(state, crtc);
+   const struct drm_connector_state *old_conn_state;
struct drm_connector *conn;
int i;
 
@@ -6381,11 +6385,12 @@ static void intel_encoders_disable(struct intel_crtc 
*crtc,
}
 }
 
-static void intel_encoders_post_disable(struct intel_crtc *crtc,
-   struct intel_crtc_state *old_crtc_state,
-   struct intel_atomic_state *state)
+static void intel_encoders_post_disable(struct intel_atomic_state *state,
+   struct intel_crtc *crtc)
 {
-   struct drm_connector_state *old_conn_state;
+   const struct intel_crtc_state *old_crtc_state =
+   intel_atomic_get_old_crtc_state(state, crtc);
+   const struct drm_connector_state *old_conn_state;
struct drm_connector *conn;
int i;
 
@@ -6401,11 +6406,12 @@ static void intel_encoders_post_disable(struct 
intel_crtc *crtc,
}
 }
 
-static void intel_encoders_post_pll_disable(struct intel_crtc *crtc,
-   struct intel_crtc_state 
*old_crtc_state,
-   struct intel_atomic_state *state)
+static void intel_encoders_post_pll_disable(struct intel_atomic_state *state,
+   struct intel_crtc *crtc)
 {
-   struct drm_connector_state *old_conn_state;
+   const struct intel_crtc_state *old_crtc_state =
+   intel_atomic_get_old_crtc_state(state, crtc);
+   const struct drm_connector_state 

Re: [Intel-gfx] [PATCH 24/27] drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all others

2019-11-12 Thread Mika Kuoppala
Chris Wilson  writes:

> Be consistent in our mocs setup on Tigerlake and set the unused control
> value to follow the PTE entry as we previously have done. The unused
> values are beyond the defines of the ABI, the consistency simplifies our
> checking.

Simplifies how?

>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c 
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 6e881c735b20..d2b445d6c258 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -489,7 +489,7 @@ static void intel_mocs_init_global(struct intel_gt *gt)
>   for (; index < table.n_entries; index++)
>   intel_uncore_write(uncore,
>  GEN12_GLOBAL_MOCS(index),
> -table.table[0].control_value);
> +table.table[I915_MOCS_PTE].control_value);

This sets it point into reserved, so I am confused.

Also the comment above and the part in generic MOCS tables will
be stale.

-Mika

>  }
>  
>  void intel_mocs_init(struct intel_gt *gt)
> -- 
> 2.24.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  1   2   >