[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: implement icl_digital_port_connected() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/icl: implement icl_digital_port_connected() (rev2)
URL   : https://patchwork.freedesktop.org/series/47151/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4537_full -> Patchwork_9760_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9760_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9760_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_9760_full:

  === IGT changes ===

 Warnings 

igt@kms_plane_lowres@pipe-b-tiling-none:
  shard-snb:  PASS -> SKIP +2


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_suspend@forcewake:
  shard-snb:  PASS -> DMESG-WARN (fdo#102365)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-hsw:  PASS -> FAIL (fdo#105363)

igt@kms_setmode@basic:
  shard-kbl:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@gem_exec_await@wide-contexts:
  shard-glk:  FAIL (fdo#105900) -> PASS

igt@kms_cursor_crc@cursor-256x256-suspend:
  shard-hsw:  INCOMPLETE (fdo#103540) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#105189) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-snb:  FAIL (fdo#103060) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS


  fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4537 -> Patchwork_9760

  CI_DRM_4537: d14ba41a37d886280f69ba42c82c34654de09efc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9760: a800e1f994246df689b693d76b41ea631d5df2fd @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/icl: implement icl_digital_port_connected()

[Lucas De Marchi]

On Tue, Jul 24, 2018 at 05:28:09PM -0700, Paulo Zanoni wrote:
> Do like the other functions and check for the status bits. The "Hot
> Plug Detection" page from our documentation says we can't just use the
> ISR bits on the CPU side, so use the correct registers.

nit: here you are saying it's for all of them rather than just a subset.
My suggestion is:

Do like the other functions and check for the status bits. For TypeC/TBT
on North Display Engine the "Hot Plug Detection" page from our
documentation says we can't just use the ISR bits to find the live
state, so use the correct registers: DFLEXDPSP TC Live State field.


> 
> v2: Rebase.
> v3:
>   - Simplify true/false assignment (Rodrigo).
>   - Reorganize is_gen if ladder (Rodrigo).
>   - Don't use the ISR for TC/TBT CPU bits.
> 
> Cc: Animesh Manna 
> Cc: Rodrigo Vivi 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  8 +
>  drivers/gpu/drm/i915/intel_dp.c | 55 -
>  2 files changed, 62 insertions(+), 1 deletion(-)
> 
> My understanding is that there's agreement on this patch since it just
> mimicks what the other gens do. Let's have this one agreed on (merged)
> first before we continue the discussions, especially since this one
> significantly affects the CI system.
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 73946055aa15..3eaff32dd74e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7210,6 +7210,7 @@ enum {
>  #define  GEN11_TC3_HOTPLUG   (1 << 18)
>  #define  GEN11_TC2_HOTPLUG   (1 << 17)
>  #define  GEN11_TC1_HOTPLUG   (1 << 16)
> +#define  GEN11_TC_HOTPLUG(tc_port)   (1 << ((tc_port) + 16))
>  #define  GEN11_DE_TC_HOTPLUG_MASK(GEN11_TC4_HOTPLUG | \
>GEN11_TC3_HOTPLUG | \
>GEN11_TC2_HOTPLUG | \
> @@ -7218,6 +7219,7 @@ enum {
>  #define  GEN11_TBT3_HOTPLUG  (1 << 2)
>  #define  GEN11_TBT2_HOTPLUG  (1 << 1)
>  #define  GEN11_TBT1_HOTPLUG  (1 << 0)
> +#define  GEN11_TBT_HOTPLUG(tc_port)  (1 << (tc_port))
>  #define  GEN11_DE_TBT_HOTPLUG_MASK   (GEN11_TBT4_HOTPLUG | \
>GEN11_TBT3_HOTPLUG | \
>GEN11_TBT2_HOTPLUG | \
> @@ -7590,6 +7592,8 @@ enum {
>  #define SDE_GMBUS_ICP(1 << 23)
>  #define SDE_DDIB_HOTPLUG_ICP (1 << 17)
>  #define SDE_DDIA_HOTPLUG_ICP (1 << 16)
> +#define SDE_TC_HOTPLUG_ICP(tc_port)  (1 << ((tc_port) + 24))
> +#define SDE_DDI_HOTPLUG_ICP(port)(1 << ((port) + 16))
>  #define SDE_DDI_MASK_ICP (SDE_DDIB_HOTPLUG_ICP | \
>SDE_DDIA_HOTPLUG_ICP)
>  #define SDE_TC_MASK_ICP  (SDE_TC4_HOTPLUG_ICP |  \
> @@ -10654,4 +10658,8 @@ enum skl_power_gate {
>   
> _ICL_DSC1_RC_BUF_THRESH_1_UDW_PB, \
>   
> _ICL_DSC1_RC_BUF_THRESH_1_UDW_PC)
>  
> +#define PORT_TX_DFLEXDPSP_MMIO(0x1638A0)
> +#define   TC_LIVE_STATE_TBT(tc_port) (1 << ((tc_port) * 8 + 6))
> +#define   TC_LIVE_STATE_TC(tc_port)  (1 << ((tc_port) * 8 + 5))
> +
>  #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index cd0f649b57a5..998d698788f9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4586,6 +4586,57 @@ static bool bxt_digital_port_connected(struct 
> intel_encoder *encoder)
>   return I915_READ(GEN8_DE_PORT_ISR) & bit;
>  }
>  
> +static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
> +  struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> +
> + return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
> +}
> +
> +static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
> +   struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + bool is_legacy, is_typec, is_tbt;
> + u32 dpsp;
> +
> + is_legacy = I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port);
> +
> + /*
> +  * The spec says we shouldn't be using the ISR bits for detecting
> +  * between TC and TBT. We should use DFLEXDPSP.
> +  */
> + dpsp = I915_READ(PORT_TX_DFLEXDPSP);

I only wonder if we should be reading the North DE even if is_legacy is
true above rather than using an early return. Anyway:

Reviewed-by: Lucas De Marchi 

Lucas De Marchi

> + is_typec = dpsp & TC_LIVE_STATE_TC(tc_port);
> + is_tbt = 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: implement icl_digital_port_connected() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/icl: implement icl_digital_port_connected() (rev2)
URL   : https://patchwork.freedesktop.org/series/47151/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4537 -> Patchwork_9760 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/47151/revisions/2/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-kbl-7560u:   PASS -> DMESG-FAIL (fdo#106947, fdo#106560)

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-glk-j4005:   PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  fi-bdw-5557u:   DMESG-FAIL (fdo#106560) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947


== Participating hosts (49 -> 41) ==

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-skl-caroline fi-byt-clapper fi-bdw-samus 


== Build changes ==

* Linux: CI_DRM_4537 -> Patchwork_9760

  CI_DRM_4537: d14ba41a37d886280f69ba42c82c34654de09efc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9760: a800e1f994246df689b693d76b41ea631d5df2fd @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a800e1f99424 drm/i915/icl: toggle PHY clock gating around link training
52d60f864c4d drm/i915/icl: program MG_DP_MODE
055dce408288 drm/i915/icl: Update FIA supported lane count for hpd.
198919f4ca28 drm/i915/icl: store the port type for TC ports
33275d39deb6 drm/i915/icl: implement icl_digital_port_connected()

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9760/issues.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 drm/i915/icl: implement icl_digital_port_connected() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/icl: implement icl_digital_port_connected() (rev2)
URL   : https://patchwork.freedesktop.org/series/47151/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/icl: implement icl_digital_port_connected()
Okay!

Commit: drm/i915/icl: store the port type for TC ports
Okay!

Commit: drm/i915/icl: Update FIA supported lane count for hpd.
-O:drivers/gpu/drm/i915/intel_dp.c:186:16: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/intel_dp.c:186:16: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)
+drivers/gpu/drm/i915/intel_dp.c:217:16: warning: expression using sizeof(void)

Commit: drm/i915/icl: program MG_DP_MODE
Okay!

Commit: drm/i915/icl: toggle PHY clock gating around link training
Okay!

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Improve clock recovery loop limit comment

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Improve clock recovery loop limit comment
URL   : https://patchwork.freedesktop.org/series/47156/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4537_full -> Patchwork_9759_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9759_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9759_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_9759_full:

  === IGT changes ===

 Possible regressions 

igt@drv_module_reload@basic-reload:
  shard-glk:  PASS -> DMESG-WARN


 Warnings 

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  SKIP -> PASS +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#102887, fdo#105363)

igt@kms_flip@plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@gem_exec_await@wide-contexts:
  shard-glk:  FAIL (fdo#105900) -> PASS

igt@kms_cursor_crc@cursor-256x256-suspend:
  shard-hsw:  INCOMPLETE (fdo#103540) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#105189) -> PASS

igt@kms_flip@dpms-vs-vblank-race:
  shard-snb:  FAIL (fdo#103060) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4537 -> Patchwork_9759

  CI_DRM_4537: d14ba41a37d886280f69ba42c82c34654de09efc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9759: 10a56f828a6f36adff10fe51812cc27c5a49e85d @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] [PATCH 2/5] drm/i915/icl: store the port type for TC ports

[Paulo Zanoni]

The type is detected based on the live status bits. Once detected,
it's not supposed to be changed, so we have some sanity checks for
that.

v2: Rebase.

Cc: Animesh Manna 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.h |  7 +
 drivers/gpu/drm/i915/intel_dp.c  | 40 ++--
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index 9292001cdd14..0a79a46d5805 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -137,6 +137,13 @@ enum tc_port {
I915_MAX_TC_PORTS
 };
 
+enum tc_port_type {
+   TC_PORT_UNKNOWN = 0,
+   TC_PORT_TYPEC,
+   TC_PORT_TBT,
+   TC_PORT_LEGACY,
+};
+
 enum dpio_channel {
DPIO_CH0,
DPIO_CH1
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 998d698788f9..90c5ba6b222b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4594,6 +4594,38 @@ static bool icl_combo_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
 }
 
+static void icl_update_tc_port_type(struct drm_i915_private *dev_priv,
+   struct intel_digital_port *intel_dig_port,
+   bool is_legacy, bool is_typec, bool is_tbt)
+{
+   enum port port = intel_dig_port->base.port;
+   enum tc_port_type old_type = intel_dig_port->tc_type;
+   const char *type_str;
+
+   WARN_ON(is_legacy + is_typec + is_tbt != 1);
+
+   if (is_legacy) {
+   intel_dig_port->tc_type = TC_PORT_LEGACY;
+   type_str = "legacy";
+   } else if (is_typec) {
+   intel_dig_port->tc_type = TC_PORT_TYPEC;
+   type_str = "typec";
+   } else if (is_tbt) {
+   intel_dig_port->tc_type = TC_PORT_TBT;
+   type_str = "tbt";
+   } else {
+   return;
+   }
+
+   /* Types are not supposed to be changed at runtime. */
+   WARN_ON(old_type != TC_PORT_UNKNOWN &&
+   old_type != intel_dig_port->tc_type);
+
+   if (old_type != intel_dig_port->tc_type)
+   DRM_DEBUG_KMS("Port %c has TC type %s\n", port_name(port),
+ type_str);
+}
+
 static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
  struct intel_digital_port *intel_dig_port)
 {
@@ -4612,9 +4644,13 @@ static bool icl_tc_port_connected(struct 
drm_i915_private *dev_priv,
is_typec = dpsp & TC_LIVE_STATE_TC(tc_port);
is_tbt = dpsp & TC_LIVE_STATE_TBT(tc_port);
 
-   WARN_ON(is_legacy + is_typec + is_tbt > 1);
+   if (!is_legacy && !is_typec && !is_tbt)
+   return false;
+
+   icl_update_tc_port_type(dev_priv, intel_dig_port, is_legacy, is_typec,
+   is_tbt);
 
-   return is_legacy || is_typec || is_tbt;
+   return true;
 }
 
 static bool icl_digital_port_connected(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c275f91244a6..5e225d8ba09a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1164,6 +1164,7 @@ struct intel_digital_port {
bool release_cl2_override;
uint8_t max_lanes;
enum intel_display_power_domain ddi_io_power_domain;
+   enum tc_port_type tc_type;
 
void (*write_infoframe)(struct drm_encoder *encoder,
const struct intel_crtc_state *crtc_state,
-- 
2.17.1

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

[Intel-gfx] [PATCH] drm/i915/icl: implement icl_digital_port_connected()

[Paulo Zanoni]

Do like the other functions and check for the status bits. The "Hot
Plug Detection" page from our documentation says we can't just use the
ISR bits on the CPU side, so use the correct registers.

v2: Rebase.
v3:
  - Simplify true/false assignment (Rodrigo).
  - Reorganize is_gen if ladder (Rodrigo).
  - Don't use the ISR for TC/TBT CPU bits.

Cc: Animesh Manna 
Cc: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h |  8 +
 drivers/gpu/drm/i915/intel_dp.c | 55 -
 2 files changed, 62 insertions(+), 1 deletion(-)

My understanding is that there's agreement on this patch since it just
mimicks what the other gens do. Let's have this one agreed on (merged)
first before we continue the discussions, especially since this one
significantly affects the CI system.

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 73946055aa15..3eaff32dd74e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7210,6 +7210,7 @@ enum {
 #define  GEN11_TC3_HOTPLUG (1 << 18)
 #define  GEN11_TC2_HOTPLUG (1 << 17)
 #define  GEN11_TC1_HOTPLUG (1 << 16)
+#define  GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 16))
 #define  GEN11_DE_TC_HOTPLUG_MASK  (GEN11_TC4_HOTPLUG | \
 GEN11_TC3_HOTPLUG | \
 GEN11_TC2_HOTPLUG | \
@@ -7218,6 +7219,7 @@ enum {
 #define  GEN11_TBT3_HOTPLUG(1 << 2)
 #define  GEN11_TBT2_HOTPLUG(1 << 1)
 #define  GEN11_TBT1_HOTPLUG(1 << 0)
+#define  GEN11_TBT_HOTPLUG(tc_port)(1 << (tc_port))
 #define  GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTPLUG | \
 GEN11_TBT3_HOTPLUG | \
 GEN11_TBT2_HOTPLUG | \
@@ -7590,6 +7592,8 @@ enum {
 #define SDE_GMBUS_ICP  (1 << 23)
 #define SDE_DDIB_HOTPLUG_ICP   (1 << 17)
 #define SDE_DDIA_HOTPLUG_ICP   (1 << 16)
+#define SDE_TC_HOTPLUG_ICP(tc_port)(1 << ((tc_port) + 24))
+#define SDE_DDI_HOTPLUG_ICP(port)  (1 << ((port) + 16))
 #define SDE_DDI_MASK_ICP   (SDE_DDIB_HOTPLUG_ICP | \
 SDE_DDIA_HOTPLUG_ICP)
 #define SDE_TC_MASK_ICP(SDE_TC4_HOTPLUG_ICP |  \
@@ -10654,4 +10658,8 @@ enum skl_power_gate {

_ICL_DSC1_RC_BUF_THRESH_1_UDW_PB, \

_ICL_DSC1_RC_BUF_THRESH_1_UDW_PC)
 
+#define PORT_TX_DFLEXDPSP  _MMIO(0x1638A0)
+#define   TC_LIVE_STATE_TBT(tc_port)   (1 << ((tc_port) * 8 + 6))
+#define   TC_LIVE_STATE_TC(tc_port)(1 << ((tc_port) * 8 + 5))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cd0f649b57a5..998d698788f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4586,6 +4586,57 @@ static bool bxt_digital_port_connected(struct 
intel_encoder *encoder)
return I915_READ(GEN8_DE_PORT_ISR) & bit;
 }
 
+static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *intel_dig_port)
+{
+   enum port port = intel_dig_port->base.port;
+
+   return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
+}
+
+static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *intel_dig_port)
+{
+   enum port port = intel_dig_port->base.port;
+   enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+   bool is_legacy, is_typec, is_tbt;
+   u32 dpsp;
+
+   is_legacy = I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port);
+
+   /*
+* The spec says we shouldn't be using the ISR bits for detecting
+* between TC and TBT. We should use DFLEXDPSP.
+*/
+   dpsp = I915_READ(PORT_TX_DFLEXDPSP);
+   is_typec = dpsp & TC_LIVE_STATE_TC(tc_port);
+   is_tbt = dpsp & TC_LIVE_STATE_TBT(tc_port);
+
+   WARN_ON(is_legacy + is_typec + is_tbt > 1);
+
+   return is_legacy || is_typec || is_tbt;
+}
+
+static bool icl_digital_port_connected(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
+
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_A:
+   case HPD_PORT_B:
+   return icl_combo_port_connected(dev_priv, dig_port);
+   case HPD_PORT_C:
+   case HPD_PORT_D:
+   case HPD_PORT_E:
+   case HPD_PORT_F:
+   return icl_tc_port_connected(dev_priv, dig_port);
+   default:
+   

[Intel-gfx] [PATCH 4/5] drm/i915/icl: program MG_DP_MODE

[Paulo Zanoni]

Programming this register is part of the Enable Sequence for
DisplayPort on ICL. Do as the spec says.

v2: Simple rebase.

Cc: Animesh Manna 
Reviewed-by: Maarten Lankhorst  (v1)
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h  | 15 
 drivers/gpu/drm/i915/intel_ddi.c |  2 +
 drivers/gpu/drm/i915/intel_dp.c  | 66 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 4 files changed, 84 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 72acecaad5c1..cf1d2bbb0613 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2092,6 +2092,21 @@ enum i915_power_well_id {
 #define   CFG_AMI_CK_DIV_OVERRIDE_VAL_MASK (0x3 << 25)
 #define   CFG_AMI_CK_DIV_OVERRIDE_EN   (1 << 24)
 
+#define MG_DP_MODE_LN0_ACU_PORT1   0x1683A0
+#define MG_DP_MODE_LN1_ACU_PORT1   0x1687A0
+#define MG_DP_MODE_LN0_ACU_PORT2   0x1693A0
+#define MG_DP_MODE_LN1_ACU_PORT2   0x1697A0
+#define MG_DP_MODE_LN0_ACU_PORT3   0x16A3A0
+#define MG_DP_MODE_LN1_ACU_PORT3   0x16A7A0
+#define MG_DP_MODE_LN0_ACU_PORT4   0x16B3A0
+#define MG_DP_MODE_LN1_ACU_PORT4   0x16B7A0
+#define MG_DP_MODE(port, ln)   \
+   MG_PHY_PORT_LN(port, ln, MG_DP_MODE_LN0_ACU_PORT1, \
+MG_DP_MODE_LN0_ACU_PORT2, \
+MG_DP_MODE_LN1_ACU_PORT1)
+#define   MG_DP_MODE_CFG_DP_X2_MODE(1 << 7)
+#define   MG_DP_MODE_CFG_DP_X1_MODE(1 << 6)
+
 /* The spec defines this only for BXT PHY0, but lets assume that this
  * would exist for PHY1 too if it had a second channel.
  */
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 01c07a000464..399c438bd210 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2809,6 +2809,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
 
intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
 
+   icl_program_mg_dp_mode(intel_dp);
+
if (IS_ICELAKE(dev_priv))
icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
level, encoder->type);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bb59e71d6f9c..28de73be4507 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -229,6 +229,72 @@ intel_dp_link_required(int pixel_clock, int bpp)
return DIV_ROUND_UP(pixel_clock * bpp, 8);
 }
 
+void icl_program_mg_dp_mode(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
+   enum port port = intel_dig_port->base.port;
+   enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+   u32 ln0, ln1, lane_info;
+
+   if (tc_port == PORT_TC_NONE || intel_dig_port->tc_type == TC_PORT_TBT)
+   return;
+
+   ln0 = I915_READ(MG_DP_MODE(port, 0));
+   ln1 = I915_READ(MG_DP_MODE(port, 1));
+
+   switch (intel_dig_port->tc_type) {
+   case TC_PORT_TYPEC:
+   ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
+   ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
+
+   lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
+DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
+   DP_LANE_ASSIGNMENT_SHIFT(tc_port);
+
+   switch (lane_info) {
+   case 0x1:
+   case 0x4:
+   break;
+   case 0x2:
+   ln0 |= MG_DP_MODE_CFG_DP_X1_MODE;
+   break;
+   case 0x3:
+   ln0 |= MG_DP_MODE_CFG_DP_X1_MODE |
+  MG_DP_MODE_CFG_DP_X2_MODE;
+   break;
+   case 0x8:
+   ln1 |= MG_DP_MODE_CFG_DP_X1_MODE;
+   break;
+   case 0xC:
+   ln1 |= MG_DP_MODE_CFG_DP_X1_MODE |
+  MG_DP_MODE_CFG_DP_X2_MODE;
+   break;
+   case 0xF:
+   ln0 |= MG_DP_MODE_CFG_DP_X1_MODE |
+  MG_DP_MODE_CFG_DP_X2_MODE;
+   ln1 |= MG_DP_MODE_CFG_DP_X1_MODE |
+  MG_DP_MODE_CFG_DP_X2_MODE;
+   break;
+   default:
+   MISSING_CASE(lane_info);
+   }
+   break;
+
+   case TC_PORT_LEGACY:
+   ln0 |= MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE;
+   ln1 |= MG_DP_MODE_CFG_DP_X1_MODE | 

[Intel-gfx] [PATCH 5/5] drm/i915/icl: toggle PHY clock gating around link training

[Paulo Zanoni]

The Gen11 TypeC PHY DDI Buffer chapter, PHY Clock Gating Programming
section says that PHY clock gating should be disabled before starting
voltage swing programming, then enabled after any link training is
complete.

v2: Simple rebase.

Cc: Animesh Manna 
Cc: Manasi Navare 
Reviewed-by: Maarten Lankhorst  (v1)
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h  | 20 ++
 drivers/gpu/drm/i915/intel_ddi.c |  3 ++
 drivers/gpu/drm/i915/intel_dp.c  | 66 
 drivers/gpu/drm/i915/intel_drv.h |  2 +
 4 files changed, 91 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cf1d2bbb0613..5530c470f30d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2106,6 +2106,26 @@ enum i915_power_well_id {
 MG_DP_MODE_LN1_ACU_PORT1)
 #define   MG_DP_MODE_CFG_DP_X2_MODE(1 << 7)
 #define   MG_DP_MODE_CFG_DP_X1_MODE(1 << 6)
+#define   MG_DP_MODE_CFG_TR2PWR_GATING (1 << 5)
+#define   MG_DP_MODE_CFG_TRPWR_GATING  (1 << 4)
+#define   MG_DP_MODE_CFG_CLNPWR_GATING (1 << 3)
+#define   MG_DP_MODE_CFG_DIGPWR_GATING (1 << 2)
+#define   MG_DP_MODE_CFG_GAONPWR_GATING(1 << 1)
+
+#define MG_MISC_SUS0_PORT1 0x168814
+#define MG_MISC_SUS0_PORT2 0x169814
+#define MG_MISC_SUS0_PORT3 0x16A814
+#define MG_MISC_SUS0_PORT4 0x16B814
+#define MG_MISC_SUS0(tc_port) \
+   _MMIO(_PORT(tc_port, MG_MISC_SUS0_PORT1, MG_MISC_SUS0_PORT2))
+#define   MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK (3 << 14)
+#define   MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(x)   ((x) << 14)
+#define   MG_MISC_SUS0_CFG_TR2PWR_GATING   (1 << 12)
+#define   MG_MISC_SUS0_CFG_CL2PWR_GATING   (1 << 11)
+#define   MG_MISC_SUS0_CFG_GAONPWR_GATING  (1 << 10)
+#define   MG_MISC_SUS0_CFG_TRPWR_GATING(1 << 7)
+#define   MG_MISC_SUS0_CFG_CL1PWR_GATING   (1 << 6)
+#define   MG_MISC_SUS0_CFG_DGPWR_GATING(1 << 5)
 
 /* The spec defines this only for BXT PHY0, but lets assume that this
  * would exist for PHY1 too if it had a second channel.
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 399c438bd210..0adc043529f2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2810,6 +2810,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
 
icl_program_mg_dp_mode(intel_dp);
+   icl_disable_phy_clock_gating(dig_port);
 
if (IS_ICELAKE(dev_priv))
icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
@@ -2828,6 +2829,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 
+   icl_enable_phy_clock_gating(dig_port);
+
intel_ddi_enable_pipe_clock(crtc_state);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28de73be4507..cc33d7c6ba19 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -295,6 +295,72 @@ void icl_program_mg_dp_mode(struct intel_dp *intel_dp)
I915_WRITE(MG_DP_MODE(port, 1), ln1);
 }
 
+void icl_enable_phy_clock_gating(struct intel_digital_port *dig_port)
+{
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   enum port port = dig_port->base.port;
+   enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+   i915_reg_t mg_regs[2] = { MG_DP_MODE(port, 0), MG_DP_MODE(port, 1) };
+   u32 val;
+   int i;
+
+   if (tc_port == PORT_TC_NONE)
+   return;
+
+   for (i = 0; i < ARRAY_SIZE(mg_regs); i++) {
+   val = I915_READ(mg_regs[i]);
+   val |= MG_DP_MODE_CFG_TR2PWR_GATING |
+  MG_DP_MODE_CFG_TRPWR_GATING |
+  MG_DP_MODE_CFG_CLNPWR_GATING |
+  MG_DP_MODE_CFG_DIGPWR_GATING |
+  MG_DP_MODE_CFG_GAONPWR_GATING;
+   I915_WRITE(mg_regs[i], val);
+   }
+
+   val = I915_READ(MG_MISC_SUS0(tc_port));
+   val |= MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3) |
+  MG_MISC_SUS0_CFG_TR2PWR_GATING |
+  MG_MISC_SUS0_CFG_CL2PWR_GATING |
+  MG_MISC_SUS0_CFG_GAONPWR_GATING |
+  MG_MISC_SUS0_CFG_TRPWR_GATING |
+  MG_MISC_SUS0_CFG_CL1PWR_GATING |
+  MG_MISC_SUS0_CFG_DGPWR_GATING;
+   I915_WRITE(MG_MISC_SUS0(tc_port), val);
+}
+
+void icl_disable_phy_clock_gating(struct intel_digital_port *dig_port)
+{
+   struct drm_i915_private 

[Intel-gfx] [PATCH 3/5] drm/i915/icl: Update FIA supported lane count for hpd.

[Paulo Zanoni]

From: Animesh Manna 

In ICL, Flexible IO Adapter (FIA) muxes data and clocks of USB 3.1,
tbt and display controller. In DP alt mode FIA configure the
number of lanes and will be used apart from DPCD read to calculate max
available lanes for DP enablement.

v2 (from Paulo): Simple rebase.

Reviewed-by: Anusha Srivatsa  (v1).
Signed-off-by: Animesh Manna 
[Paulo: significant rewrite of the patch.]
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 drivers/gpu/drm/i915/intel_dp.c | 33 -
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 93de6f724e77..72acecaad5c1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10705,5 +10705,8 @@ enum skl_power_gate {
 #define PORT_TX_DFLEXDPSP  _MMIO(0x1638A0)
 #define   TC_LIVE_STATE_TBT(tc_port)   (1 << ((tc_port) * 8 + 6))
 #define   TC_LIVE_STATE_TC(tc_port)(1 << ((tc_port) * 8 + 5))
+#define   DP_LANE_ASSIGNMENT_SHIFT(tc_port)((tc_port) * 8)
+#define   DP_LANE_ASSIGNMENT_MASK(tc_port) (0xf << ((tc_port) * 8))
+#define   DP_LANE_ASSIGNMENT(tc_port, x)   ((x) << ((tc_port) * 8))
 
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90c5ba6b222b..bb59e71d6f9c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -176,14 +176,45 @@ static int intel_dp_max_common_rate(struct intel_dp 
*intel_dp)
return intel_dp->common_rates[intel_dp->num_common_rates - 1];
 }
 
+static int intel_dp_get_fia_supported_lane_count(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
+   u32 lane_info;
+
+   if (tc_port == PORT_TC_NONE || dig_port->tc_type != TC_PORT_TYPEC)
+   return 4;
+
+   lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
+DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
+   DP_LANE_ASSIGNMENT_SHIFT(tc_port);
+
+   switch (lane_info) {
+   default:
+   MISSING_CASE(lane_info);
+   case 1:
+   case 2:
+   case 4:
+   case 8:
+   return 1;
+   case 3:
+   case 12:
+   return 2;
+   case 15:
+   return 4;
+   }
+}
+
 /* Theoretical max between source and sink */
 static int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
int source_max = intel_dig_port->max_lanes;
int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
+   int fia_max = intel_dp_get_fia_supported_lane_count(intel_dp);
 
-   return min(source_max, sink_max);
+   return min3(source_max, sink_max, fia_max);
 }
 
 int intel_dp_max_lane_count(struct intel_dp *intel_dp)
-- 
2.17.1

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

[Intel-gfx] [PATCH 0/5] Remaining ICL display patches, v2

[Paulo Zanoni]

Hi

This new version of the series excludes the controversial patch about
the HPD connect flow. Let's reach an agreement on this part first,
then we discuss what to do without having to rebase too many times the
patches we already agree on. Only patches 1 and 2 need review.

Cc: Rodrigo Vivi 

Thanks,
Paulo

Animesh Manna (1):
  drm/i915/icl: Update FIA supported lane count for hpd.

Paulo Zanoni (4):
  drm/i915/icl: implement icl_digital_port_connected()
  drm/i915/icl: store the port type for TC ports
  drm/i915/icl: program MG_DP_MODE
  drm/i915/icl: toggle PHY clock gating around link training

 drivers/gpu/drm/i915/i915_reg.h  |  46 +
 drivers/gpu/drm/i915/intel_ddi.c |   5 +
 drivers/gpu/drm/i915/intel_display.h |   7 +
 drivers/gpu/drm/i915/intel_dp.c  | 256 ++-
 drivers/gpu/drm/i915/intel_drv.h |   4 +
 5 files changed, 316 insertions(+), 2 deletions(-)

-- 
2.17.1

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Improve clock recovery loop limit comment

[Marc Herbert]

Reviewed-by: Marc Herbert 

Thx Nathan, I think this helps. I'm still curious how training normally
converges much faster than the total number of possibilities but - unlike
this latest clarification below - I expect the spec(s) to document that.


On 24/07/2018 15:33, Nathan Ciobanu wrote:
> Clarifies the clock recovery loop limit comment that 80
> max_cr_tries for pre-DP1.4 devices was chosen as a very
> tolerant upper bound.
> Assumptions made:
> - DP1.4 syncs should be smarter so they won't need more
> than 10 tries
> - pre-DP1.4 syncs should be compliant enough to not need
> that many tries (80) but we should tolerate any that may
> trigger this corner case
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Cc: Marc Herbert 
> Suggested-by: Marc Herbert 
> Signed-off-by: Nathan Ciobanu 
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 07e128c7443c..a9f40985a621 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -172,10 +172,12 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   }
>  
>   /*
> -  * DP 1.4 spec clock recovery retries defined but
> -  * for devices pre-DP 1.4 we set the retry limit
> -  * to 4 (voltage levels) x 4 (preemphasis levels) x
> -  * x 5 (same voltage retries) = 80 (max iterations)
> +  * The DP 1.4 spec defines the max clock recovery retries value
> +  * as 10 but for pre-DP 1.4 devices we set a very tolerant
> +  * retry limit of 80 (4 voltage levels x 4 preemphasis levels x
> +  * x 5 identical voltage retries). Since the previous specs didn't
> +  * define a limit and created the possibility of an infinite loop
> +  * we want to prevent any sync from triggering that corner case.
>*/
>   if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
>   max_cr_tries = 10;
> 

___
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/icl: implement icl_digital_port_connected()

[Patchwork]

== Series Details ==

Series: drm/i915/icl: implement icl_digital_port_connected()
URL   : https://patchwork.freedesktop.org/series/47151/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4536_full -> Patchwork_9758_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9758_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9758_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_9758_full:

  === IGT changes ===

 Warnings 

igt@gem_mocs_settings@mocs-rc6-vebox:
  shard-kbl:  SKIP -> PASS


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665, fdo#106023)

igt@kms_flip@basic-flip-vs-wf_vblank:
  shard-glk:  PASS -> FAIL (fdo#103928)


 Possible fixes 

igt@drv_suspend@shrink:
  shard-snb:  INCOMPLETE (fdo#106886, fdo#105411) -> PASS

igt@gem_workarounds@suspend-resume:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#105189) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS


 Warnings 

igt@drv_suspend@shrink:
  shard-glk:  FAIL (fdo#106886) -> INCOMPLETE (fdo#106886, 
fdo#103359, k.org#198133)


  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4536 -> Patchwork_9758

  CI_DRM_4536: f760bdbf2f81ebf6045e925d60fff2084b756ac7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9758: 322df57ab79b4cd0bd0ff81b17734688395aa97e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9758/shards.html
___
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/dp: Improve clock recovery loop limit comment

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Improve clock recovery loop limit comment
URL   : https://patchwork.freedesktop.org/series/47156/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4537 -> Patchwork_9759 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/47156/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-kbl-7560u:   PASS -> DMESG-FAIL (fdo#106947, fdo#106560)

igt@drv_selftest@live_workarounds:
  fi-cfl-8700k:   PASS -> DMESG-FAIL (fdo#107292)
  {fi-bsw-kefka}: PASS -> DMESG-FAIL (fdo#107292)

igt@kms_flip@basic-flip-vs-modeset:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106097, fdo#106000)

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-glk-j4005:   PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  fi-bdw-5557u:   DMESG-FAIL (fdo#106560) -> PASS


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

  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (49 -> 41) ==

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-skl-caroline fi-byt-clapper fi-bdw-samus 


== Build changes ==

* Linux: CI_DRM_4537 -> Patchwork_9759

  CI_DRM_4537: d14ba41a37d886280f69ba42c82c34654de09efc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9759: 10a56f828a6f36adff10fe51812cc27c5a49e85d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

10a56f828a6f drm/i915/dp: Improve clock recovery loop limit comment

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/dp: Improve clock recovery loop limit comment

[Nathan Ciobanu]

Clarifies the clock recovery loop limit comment that 80
max_cr_tries for pre-DP1.4 devices was chosen as a very
tolerant upper bound.
Assumptions made:
- DP1.4 syncs should be smarter so they won't need more
than 10 tries
- pre-DP1.4 syncs should be compliant enough to not need
that many tries (80) but we should tolerate any that may
trigger this corner case

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Suggested-by: Marc Herbert 
Signed-off-by: Nathan Ciobanu 

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 07e128c7443c..a9f40985a621 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -172,10 +172,12 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
}
 
/*
-* DP 1.4 spec clock recovery retries defined but
-* for devices pre-DP 1.4 we set the retry limit
-* to 4 (voltage levels) x 4 (preemphasis levels) x
-* x 5 (same voltage retries) = 80 (max iterations)
+* The DP 1.4 spec defines the max clock recovery retries value
+* as 10 but for pre-DP 1.4 devices we set a very tolerant
+* retry limit of 80 (4 voltage levels x 4 preemphasis levels x
+* x 5 identical voltage retries). Since the previous specs didn't
+* define a limit and created the possibility of an infinite loop
+* we want to prevent any sync from triggering that corner case.
 */
if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
max_cr_tries = 10;
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: implement icl_digital_port_connected()

[Patchwork]

== Series Details ==

Series: drm/i915/icl: implement icl_digital_port_connected()
URL   : https://patchwork.freedesktop.org/series/47151/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4536 -> Patchwork_9758 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/47151/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-skl-6260u:   PASS -> DMESG-FAIL (fdo#107174, fdo#106560)

igt@kms_flip@basic-plain-flip:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#105719)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: DMESG-FAIL (fdo#107292) -> PASS
  fi-skl-6700k2:  DMESG-FAIL (fdo#107292) -> PASS

igt@kms_flip@basic-flip-vs-dpms:
  fi-glk-j4005:   DMESG-WARN (fdo#106000, fdo#106097) -> PASS

{igt@kms_psr@primary_page_flip}:
  fi-kbl-7560u:   FAIL (fdo#107336) -> PASS


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

  fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
  fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
  fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336


== Participating hosts (49 -> 40) ==

  Missing(9): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 fi-skl-caroline fi-byt-clapper fi-bdw-samus 


== Build changes ==

* Linux: CI_DRM_4536 -> Patchwork_9758

  CI_DRM_4536: f760bdbf2f81ebf6045e925d60fff2084b756ac7 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9758: 322df57ab79b4cd0bd0ff81b17734688395aa97e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

322df57ab79b drm/i915/icl: implement icl_digital_port_connected()

== Logs ==

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

Re: [Intel-gfx] [PATCH v9 7/7] drm/i915: add a sysfs entry to let users set sseu configs

[Bloomfield, Jon]

Gratuitous top posting to re-kick the thread.

For Gen11 we can't have an on/off switch anyway (media simply won't run
with an oncompatible slice config), so let's agree on an api to allow userland
to select the slice configuration for its contexts, for Gen11 only. I'd prefer a
simple {MediaConfig/GeneralConfig} type context param but I really don't
care that much.

For gen9/10 it's arguable whether we need this at all. The effect on media
workloads varies, but I'm guessing normal users (outside a transcode
type environment) will never know they're missing anything. Either way,
we can continue discussing while we progress the gen11 solution.

Jon

> -Original Message-
> From: Intel-gfx  On Behalf Of
> Bloomfield, Jon
> Sent: Wednesday, July 18, 2018 9:44 AM
> To: Tvrtko Ursulin ; Joonas Lahtinen
> ; Chris Wilson ;
> Landwerlin, Lionel G ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v9 7/7] drm/i915: add a sysfs entry to let 
> users
> set sseu configs
> 
> > -Original Message-
> > From: Intel-gfx  On Behalf Of
> > Tvrtko Ursulin
> > Sent: Thursday, June 14, 2018 1:29 AM
> > To: Joonas Lahtinen ; Chris Wilson
> > ; Landwerlin, Lionel G
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v9 7/7] drm/i915: add a sysfs entry to let
> users
> > set sseu configs
> >
> >
> > On 13/06/2018 13:49, Joonas Lahtinen wrote:
> > > Quoting Tvrtko Ursulin (2018-06-12 15:02:07)
> > >>
> > >> On 12/06/2018 11:52, Lionel Landwerlin wrote:
> > >>> On 12/06/18 11:37, Chris Wilson wrote:
> >  Quoting Lionel Landwerlin (2018-06-12 11:33:34)
> > > On 12/06/18 10:20, Joonas Lahtinen wrote:
> > >> Quoting Chris Wilson (2018-06-11 18:02:37)
> > >>> Quoting Lionel Landwerlin (2018-06-11 14:46:07)
> >  On 11/06/18 13:10, Tvrtko Ursulin wrote:
> > > On 30/05/2018 15:33, Lionel Landwerlin wrote:
> > >> There are concerns about denial of service around the per
> > >> context sseu
> > >> configuration capability. In a previous commit introducing the
> > >> capability we allowed it only for capable users. This changes
> > >> adds a
> > >> new debugfs entry to let any user configure its own context
> > >> powergating setup.
> > > As far as I understood it, Joonas' concerns here are:
> > >
> > > 1) That in the containers use case individual containers
> wouldn't
> > be
> > > able to turn on the sysfs toggle for them.
> > >
> > > 2) That also in the containers use case if box admin turns on
> the
> > > feature, some containers would potentially start negatively
> > > affecting
> > > the others (via the accumulated cost of slice re-configuration
> on
> > > context switching).
> > >
> > > I am not familiar with typical container setups to be
> authoritative
> > > here, but intuitively I find it reasonable that a low-level
> hardware
> > > switch like this would be under the control of a master domain
> > > administrator. ("If you are installing our product in the
> container
> > > environment, make sure your system administrator enables
> this
> > > hardware
> > > feature.", "Note to system administrators: Enabling this
> features
> > > may
> > > negatively affect the performance of other containers.")
> > >
> > > Alternative proposal is for the i915 to apply an "or" filter on 
> > > all
> > > requested masks and in that way ensure dynamic re-
> > configuration
> > > doesn't happen on context switches, but driven from
> userspace
> > via
> > > ioctls.
> > >
> > > In other words, should _all_ userspace agree between
> > themselves that
> > > they want to turn off a slice, they would then need to send out
> a
> > > concerted ioctl storm, where number of needed ioctls equals
> > the
> > > number
> > > of currently active contexts. (This may have its own
> performance
> > > consequences caused by the barriers needed to modify all
> > context
> > > images.)
> > >
> > > This was deemed acceptable the the media use case, but my
> > concern is
> > > the approach is not elegant and will tie us with the "or" policy
> in
> > > the ABI. (Performance concerns I haven't evaluated yet, but
> > they
> > > also
> > > may be significant.)
> > >
> > > If we go back thinking about the containers use case, then it
> > > transpires that even though the "or" policy does prevent one
> > > container
> > > from affecting the other from one angle, it also prevents one
> > > container from exercising the feature unless all containers
> > > co-operate.
> > >
> > > As such, we can view the original problem statement where
> we
> > have an

[Intel-gfx] [PATCH] drm/i915/icl: implement icl_digital_port_connected()

[Paulo Zanoni]

Do like the other functions and check for the status bits. The "Hot
Plug Detection" page from our documentation says we can't just use the
ISR bits on the CPU side, so use the correct registers.

v2: Rebase.
v3:
  - Simplify true/false assignment (Rodrigo).
  - Reorganize is_gen if ladder (Rodrigo).
  - Don't use the ISR for TC/TBT CPU bits.

Cc: Animesh Manna 
Cc: Rodrigo Vivi 
Reviewed-by: Lucas De Marchi  (v1)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_reg.h |  8 +
 drivers/gpu/drm/i915/intel_dp.c | 55 -
 2 files changed, 62 insertions(+), 1 deletion(-)

My understanding is that there's agreement on this patch since it just
mimicks what the other gens do. Let's have this one agreed on (merged)
first before we continue the discussions, especially since this one
significantly affects the CI system.

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 73946055aa15..3eaff32dd74e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7210,6 +7210,7 @@ enum {
 #define  GEN11_TC3_HOTPLUG (1 << 18)
 #define  GEN11_TC2_HOTPLUG (1 << 17)
 #define  GEN11_TC1_HOTPLUG (1 << 16)
+#define  GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 16))
 #define  GEN11_DE_TC_HOTPLUG_MASK  (GEN11_TC4_HOTPLUG | \
 GEN11_TC3_HOTPLUG | \
 GEN11_TC2_HOTPLUG | \
@@ -7218,6 +7219,7 @@ enum {
 #define  GEN11_TBT3_HOTPLUG(1 << 2)
 #define  GEN11_TBT2_HOTPLUG(1 << 1)
 #define  GEN11_TBT1_HOTPLUG(1 << 0)
+#define  GEN11_TBT_HOTPLUG(tc_port)(1 << (tc_port))
 #define  GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTPLUG | \
 GEN11_TBT3_HOTPLUG | \
 GEN11_TBT2_HOTPLUG | \
@@ -7590,6 +7592,8 @@ enum {
 #define SDE_GMBUS_ICP  (1 << 23)
 #define SDE_DDIB_HOTPLUG_ICP   (1 << 17)
 #define SDE_DDIA_HOTPLUG_ICP   (1 << 16)
+#define SDE_TC_HOTPLUG_ICP(tc_port)(1 << ((tc_port) + 24))
+#define SDE_DDI_HOTPLUG_ICP(port)  (1 << ((port) + 16))
 #define SDE_DDI_MASK_ICP   (SDE_DDIB_HOTPLUG_ICP | \
 SDE_DDIA_HOTPLUG_ICP)
 #define SDE_TC_MASK_ICP(SDE_TC4_HOTPLUG_ICP |  \
@@ -10654,4 +10658,8 @@ enum skl_power_gate {

_ICL_DSC1_RC_BUF_THRESH_1_UDW_PB, \

_ICL_DSC1_RC_BUF_THRESH_1_UDW_PC)
 
+#define PORT_TX_DFLEXDPSP  _MMIO(0x1638A0)
+#define   TC_LIVE_STATE_TBT(tc_port)   (1 << ((tc_port) * 8 + 6))
+#define   TC_LIVE_STATE_TC(tc_port)(1 << ((tc_port) * 8 + 5))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cd0f649b57a5..998d698788f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4586,6 +4586,57 @@ static bool bxt_digital_port_connected(struct 
intel_encoder *encoder)
return I915_READ(GEN8_DE_PORT_ISR) & bit;
 }
 
+static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *intel_dig_port)
+{
+   enum port port = intel_dig_port->base.port;
+
+   return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
+}
+
+static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *intel_dig_port)
+{
+   enum port port = intel_dig_port->base.port;
+   enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+   bool is_legacy, is_typec, is_tbt;
+   u32 dpsp;
+
+   is_legacy = I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port);
+
+   /*
+* The spec says we shouldn't be using the ISR bits for detecting
+* between TC and TBT. We should use DFLEXDPSP.
+*/
+   dpsp = I915_READ(PORT_TX_DFLEXDPSP);
+   is_typec = dpsp & TC_LIVE_STATE_TC(tc_port);
+   is_tbt = dpsp & TC_LIVE_STATE_TBT(tc_port);
+
+   WARN_ON(is_legacy + is_typec + is_tbt > 1);
+
+   return is_legacy || is_typec || is_tbt;
+}
+
+static bool icl_digital_port_connected(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
+
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_A:
+   case HPD_PORT_B:
+   return icl_combo_port_connected(dev_priv, dig_port);
+   case HPD_PORT_C:
+   case HPD_PORT_D:
+   case HPD_PORT_E:
+   case HPD_PORT_F:
+   return icl_tc_port_connected(dev_priv, dig_port);
+  

Re: [Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Rodrigo Vivi]

On Tue, Jul 24, 2018 at 10:23:30PM +0200, Marcin Owsiany wrote:
>2018-07-24 20:37 GMT+02:00 Rodrigo Vivi <[1]rodrigo.v...@intel.com>:
> 
>  On Sat, Jul 21, 2018 at 09:43:53AM +0200, Marcin Owsiany wrote:
>  >pt., 20 lip 2018, 23:35 użytkownik Rodrigo Vivi
>  ><[1][2]rodrigo.v...@intel.com> napisał:
>  >
>  >  On Fri, Jul 20, 2018 at 11:01:38PM +0200, Marcin Owsiany
>  wrote:
>  >  >2018-07-20 22:22 GMT+02:00 Rodrigo Vivi
>  >  <[1][2][3]rodrigo.v...@intel.com>:
>  >  >
>  >  >On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany
>  wrote:
>  >  >PS: Sorry for the initial double-post, I thought my
>  first email
>  >  was
>  >  >blackholed
>  >  np... I approved it as soon as I saw it there.
>  >  list is open, but I have to filter the non-subscribed emails
>  because
>  >  of
>  >  so many spams...
>  >
>  >I see, perhaps it might make sense to mention that the list is
>  >moderated to
>  >[3][4]https://01.org/community/participation-guidelines#list
>  >Currently the policy makes it sound like messages from
>  non-subscribers
>  >are doomed for good.
>  Well, we have this link on list's main page:
>  [5]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>  So I'm not sure where you are suggesting us to add this link.
> 
>I'm not suggesting to add this link (I know it's there, that's how I
>found it in the first place).
>I'm suggesting to change the contents
>of [6]https://01.org/community/participation-guidelines#list to say
>"your posts will need to wait for moderation if you're not subscribed"
>rather than "you need to be subscribed to post".

Oh I see.

These 01.org guidelines are a meta for 01.org related projects, not just
for graphics.

And I just noticed their "rules" state for subscribers only. What it
is not our case. Ours is public, but moderated to avoid spams.

Maybe it would be better to create our own description instead of having
this link there.

>Marcin
> 
> References
> 
>1. mailto:rodrigo.v...@intel.com
>2. mailto:rodrigo.v...@intel.com
>3. mailto:rodrigo.v...@intel.com
>4. https://01.org/community/participation-guidelines#list
>5. https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>6. https://01.org/community/participation-guidelines#list
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for Add Colorspace connector property interface

[Patchwork]

== Series Details ==

Series: Add Colorspace connector property interface
URL   : https://patchwork.freedesktop.org/series/47132/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4535_full -> Patchwork_9757_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9757_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9757_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_9757_full:

  === IGT changes ===

 Warnings 

igt@pm_rc6_residency@rc6-accuracy:
  shard-kbl:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_exec_flush@basic-wb-rw-default:
  shard-snb:  PASS -> INCOMPLETE (fdo#105411)

igt@gem_ppgtt@blt-vs-render-ctx0:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665, fdo#106023)

igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#100368) +1

igt@kms_flip@plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#103928) +1

igt@kms_setmode@basic:
  shard-apl:  PASS -> FAIL (fdo#99912)


 Possible fixes 

igt@kms_flip@flip-vs-expired-vblank:
  shard-glk:  FAIL (fdo#102887) -> PASS

igt@kms_rotation_crc@sprite-rotation-270:
  shard-apl:  FAIL (fdo#103925) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4535 -> Patchwork_9757

  CI_DRM_4535: 79a6a05d5beb28987746b0ea61837783a4af4e82 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9757: bfaa2413cf37fbf7ef53ddaa67b122e20f4edd2e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Marcin Owsiany]

2018-07-24 20:37 GMT+02:00 Rodrigo Vivi :

> On Sat, Jul 21, 2018 at 09:43:53AM +0200, Marcin Owsiany wrote:
> >pt., 20 lip 2018, 23:35 użytkownik Rodrigo Vivi
> ><[1]rodrigo.v...@intel.com> napisał:
> >
> >  On Fri, Jul 20, 2018 at 11:01:38PM +0200, Marcin Owsiany wrote:
> >  >2018-07-20 22:22 GMT+02:00 Rodrigo Vivi
> >  <[1][2]rodrigo.v...@intel.com>:
> >  >
> >  >On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
> >  >PS: Sorry for the initial double-post, I thought my first email
> >  was
> >  >blackholed
> >  np... I approved it as soon as I saw it there.
> >  list is open, but I have to filter the non-subscribed emails because
> >  of
> >  so many spams...
> >
> >I see, perhaps it might make sense to mention that the list is
> >moderated to
> >[3]https://01.org/community/participation-guidelines#list
> >Currently the policy makes it sound like messages from non-subscribers
> >are doomed for good.
>
> Well, we have this link on list's main page:
>
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> So I'm not sure where you are suggesting us to add this link.
>

I'm not suggesting to add this link (I know it's there, that's how I found
it in the first place).
I'm suggesting to change the contents of
https://01.org/community/participation-guidelines#list to say "your posts
will need to wait for moderation if you're not subscribed" rather than "you
need to be subscribed to post".

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

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Andrew Morton]

On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko  wrote:

> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> > 
> > - comment "failed to reap part..." is misleading - sounds like it's
> >   referring to something which happened in the past, is in fact
> >   referring to something which might happen in the future.
> > 
> > - fails to call trace_finish_task_reaping() in one case
> > 
> > - code duplication.
> > 
> > - Increases mmap_sem hold time a little by moving
> >   trace_finish_task_reaping() inside the locked region.  So sue me ;)
> > 
> > - Sharing the finish: path means that the trace event won't
> >   distinguish between the two sources of finishing.
> > 
> > Please take a look?
> 
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 104ef4a01a55..88657e018714 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk, 
> struct mm_struct *mm)
>   /* failed to reap part of the address space. Try again later */
>   if (!__oom_reap_task_mm(mm)) {
>   up_read(>mmap_sem);
> - return true;
> + return false;
>   }
>  
>   pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, 
> file-rss:%lukB, shmem-rss:%lukB\n",

OK, thanks, I added that.

> 
> On top of that the proposed cleanup looks as follows:
> 

Looks good to me.  Seems a bit strange that we omit the pr_info()
output if the mm was partially reaped - people would still want to know
this?   Not very important though.

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

Re: [Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Rodrigo Vivi]

On Sat, Jul 21, 2018 at 09:43:53AM +0200, Marcin Owsiany wrote:
>pt., 20 lip 2018, 23:35 użytkownik Rodrigo Vivi
><[1]rodrigo.v...@intel.com> napisał:
> 
>  On Fri, Jul 20, 2018 at 11:01:38PM +0200, Marcin Owsiany wrote:
>  >2018-07-20 22:22 GMT+02:00 Rodrigo Vivi
>  <[1][2]rodrigo.v...@intel.com>:
>  >
>  >On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
>  >PS: Sorry for the initial double-post, I thought my first email
>  was
>  >blackholed
>  np... I approved it as soon as I saw it there.
>  list is open, but I have to filter the non-subscribed emails because
>  of
>  so many spams...
> 
>I see, perhaps it might make sense to mention that the list is
>moderated to
>[3]https://01.org/community/participation-guidelines#list
>Currently the policy makes it sound like messages from non-subscribers
>are doomed for good.

Well, we have this link on list's main page:

https://lists.freedesktop.org/mailman/listinfo/intel-gfx

So I'm not sure where you are suggesting us to add this link.

>Marcin
> 
> References
> 
>1. mailto:rodrigo.v...@intel.com
>2. mailto:rodrigo.v...@intel.com
>3. https://01.org/community/participation-guidelines#list

> ___
> 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 v4 1/5] drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias

[Michal Wajdeczko]

On Fri, 20 Jul 2018 15:33:51 +0200, Jakub Bartmiński  
 wrote:



It would appear that the calculated GuC pin bias was larger than it
should be, as the GuC address space does NOT contain the "HW contexts  
RSVD"

part of the WOPCM. Thus, the GuC pin bias is simply the GuC WOPCM size.

Signed-off-by: Jakub Bartmiński 
Cc: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc.c | 50 ++--
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c  
b/drivers/gpu/drm/i915/intel_guc.c

index e12bd259df17..17753952933e 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -582,50 +582,44 @@ int intel_guc_resume(struct intel_guc *guc)
  *
  * ::
  *
- * +==> ++ <== GUC_GGTT_TOP
- * ^||
- * |||
- * ||DRAM|
- * ||   Memory   |
- * |||
- *GuC   ||
- *  Address  +> ++ <== WOPCM Top
- *   Space   ^  |   HW contexts RSVD |
- * | |  |WOPCM   |
- * | | +==> ++ <== GuC WOPCM Top
- * |GuC^||
- * |GGTT   |||
- * |Pin   GuC   |GuC |
- * |Bias WOPCM  |   WOPCM|
- * | |Size  ||
- * | | |||
- * v v v||
- * +=+=+==> ++ <== GuC WOPCM Base
- *  |   Non-GuC WOPCM|
- *  |   (HuC/Reserved)   |
- *  ++ <== WOPCM Base
+ * +> ++ <== GUC_GGTT_TOP
+ * ^  ||
+ * |  ||
+ * |  |DRAM|
+ * |  |   Memory   |
+ * |  ||
+ *GuC ||
+ *  Address+> ++ <== GuC WOPCM Top
+ *   Space ^  ||
+ * |   |  ||
+ * |  GuC |GuC |
+ * | WOPCM|   WOPCM|
+ * |  Size||
+ * |   |  ||
+ * v   v  ||
+ * +===+> ++ <== GuC WOPCM Base


as things are now simpler, can you clarify this diagram little more,
like this:

+ --- ++ <=  
^ |  Reserved  |
| ++ <= GUC_GGTT_TOP
| ||
   GuC|   DRAM |
 Address  ||
  Space  + -- ++ <= GuC's ggtt_pin_bias
|^||
||||
|   GuC   ||
|  WOPCM  |   WOPCM|
|   Size  ||
||||
vv||
+ -- + -- ++ <=  



  *
  * The lower part of GuC Address Space [0, ggtt_pin_bias) is mapped to  
WOPCM
  * while upper part of GuC Address Space [ggtt_pin_bias, GUC_GGTT_TOP)  
is mapped
- * to DRAM. The value of the GuC ggtt_pin_bias is determined by WOPCM  
size and

- * actual GuC WOPCM size.
+ * to DRAM. The value of the GuC ggtt_pin_bias is the GuC WOPCM size.
  */
/**
  * guc_init_ggtt_pin_bias() - Initialize the GuC ggtt_pin_bias value.
  * @guc: intel_guc structure.
  *
- * This function will calculate and initialize the ggtt_pin_bias value  
based on

- * overall WOPCM size and GuC WOPCM size.
+ * This function will calculate and initialize the ggtt_pin_bias value
+ * based on the GuC WOPCM size.
  */
 static void guc_init_ggtt_pin_bias(struct intel_guc *guc)
 {
struct drm_i915_private *i915 = guc_to_i915(guc);
GEM_BUG_ON(!i915->wopcm.size);


hmm, maybe we should only care about i915->wopcm.guc.size ?


-   GEM_BUG_ON(i915->wopcm.size < i915->wopcm.guc.base);
+   GEM_BUG_ON(range_overflows(i915->wopcm.guc.base, i915->wopcm.guc.size,
+  i915->wopcm.size));


why do you want to validate base/size here? you don't use guc.base anymore
and, btw, it should be already calculated/verified in intel_wopcm.c


-   guc->ggtt_pin_bias = i915->wopcm.size - i915->wopcm.guc.base;
+   guc->ggtt_pin_bias = i915->wopcm.guc.size;
 }
/**


maybe we should also add

Bspec: 1180

as patch seems to be aligned with it

with all above,

Reviewed-by: Michal 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Protect guc_fini_wq() against module load abort (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Protect guc_fini_wq() against module load abort (rev2)
URL   : https://patchwork.freedesktop.org/series/47127/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4534_full -> Patchwork_9756_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_9756_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9756_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_9756_full:

  === IGT changes ===

 Possible regressions 

igt@gem_eio@in-flight-contexts-10ms:
  shard-snb:  PASS -> FAIL


 Warnings 

igt@gem_exec_schedule@deep-bsd2:
  shard-kbl:  PASS -> SKIP +2

igt@pm_rc6_residency@rc6-accuracy:
  shard-snb:  PASS -> SKIP


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@gem_ctx_isolation@vecs0-s3:
  shard-apl:  PASS -> FAIL (fdo#103375)

igt@gem_ppgtt@blt-vs-render-ctxn:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665, fdo#106023)

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-hsw:  PASS -> FAIL (fdo#103060)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  shard-kbl:  PASS -> INCOMPLETE (fdo#103665)

igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
  shard-snb:  PASS -> DMESG-WARN (fdo#102365)


 Possible fixes 

igt@drv_suspend@shrink:
  shard-apl:  FAIL (fdo#106886) -> PASS

igt@kms_fbcon_fbt@fbc:
  shard-apl:  INCOMPLETE (fdo#103927) -> PASS

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  FAIL (fdo#105363) -> PASS

igt@kms_flip@basic-flip-vs-wf_vblank:
  shard-glk:  FAIL (fdo#100368) -> PASS

igt@perf@polling:
  shard-hsw:  FAIL (fdo#102252) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
  fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4534 -> Patchwork_9756

  CI_DRM_4534: a59bbda34ede6f5685fdc86b58f143bada751617 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4572: 9b064015df14506b23cd2d7245a73e1b1d16ee1f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9756: cbd1dfaa9f3c1b9dff51c78195c666f41ba53f20 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

[Intel-gfx] [PATCH 01/13] include: Move ascii85 functions from i915 to linux/ascii85.h

[Jordan Crouse]

The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.

v4: Make the return value const char * as suggested by Chris Wilson
v3: Fix error_puts -> err_puts pointed out by the 01.org bot
v2: Update API to be cleaner for the caller as suggested by Chris Wilson

Reviewed-by: Chris Wilson 
Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 34 +++-
 include/linux/ascii85.h   | 38 +++
 2 files changed, 42 insertions(+), 30 deletions(-)
 create mode 100644 include/linux/ascii85.h

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index df234dc23274..284e899ca8ff 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_gpu_error.h"
 #include "i915_drv.h"
@@ -522,35 +523,12 @@ void i915_error_printf(struct drm_i915_error_state_buf 
*e, const char *f, ...)
va_end(args);
 }
 
-static int
-ascii85_encode_len(int len)
-{
-   return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
-   int i;
-
-   if (in == 0)
-   return false;
-
-   out[5] = '\0';
-   for (i = 5; i--; ) {
-   out[i] = '!' + in % 85;
-   in /= 85;
-   }
-
-   return true;
-}
-
 static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
struct drm_i915_error_object *obj)
 {
-   char out[6];
+   char out[ASCII85_BUFSZ];
int page;
 
if (!obj)
@@ -572,12 +550,8 @@ static void print_error_obj(struct 
drm_i915_error_state_buf *m,
len -= obj->unused;
len = ascii85_encode_len(len);
 
-   for (i = 0; i < len; i++) {
-   if (ascii85_encode(obj->pages[page][i], out))
-   err_puts(m, out);
-   else
-   err_puts(m, "z");
-   }
+   for (i = 0; i < len; i++)
+   err_puts(m, ascii85_encode(obj->pages[page][i], out));
}
err_puts(m, "\n");
 }
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index ..4cc40201273e
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,38 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2008 Intel Corporation
+ * Copyright (c) 2018 The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include 
+
+#define ASCII85_BUFSZ 6
+
+static inline long
+ascii85_encode_len(long len)
+{
+   return DIV_ROUND_UP(len, 4);
+}
+
+static inline const char *
+ascii85_encode(u32 in, char *out)
+{
+   int i;
+
+   if (in == 0)
+   return "z";
+
+   out[5] = '\0';
+   for (i = 5; i--; ) {
+   out[i] = '!' + in % 85;
+   in /= 85;
+   }
+
+   return out;
+}
+
+#endif
-- 
2.18.0

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Rodrigo Vivi]

On Mon, Jul 23, 2018 at 02:27:35PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> 
> Read from DPCD once for all 3 values as this is an expensive operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
> 
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh.
> 
> This patch helps with backward compatibility for devices pre DP1.3.
> 
> v2: read only dpcd values which can be affected, remove incorrect check,
> split into drm include changes into separate patch, commit message,
> verbose debugging statements during overwrite.
> v3: white space fixes
> v4: make path dependent on DPCD revision > 1.2
> v5: split into function, removed DPCD rev check
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 54 +
>  1 file changed, 54 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..ed16b93bfe40 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3731,6 +3731,58 @@ intel_dp_link_down(struct intel_encoder *encoder,
>   }
>  }
>  
> +static void
> +intel_dp_extended_receiver_capabilities(struct intel_dp *intel_dp)
> +{
> + /*
> +  * Prior to DP1.3 the bit represented by
> +  * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved.
> +  * if it is set DP_DPCD_REV at h could be at a value less than
> +  * the true capability of the panel. The only way to check is to
> +  * then compare h and 2200h.
> +  */
> + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT) {
> + uint8_t dpcd_ext[6];
> +
> + DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field 
> Present, accessing 02200h through 022FFh\n");
> +
> + if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
> +  _ext, sizeof(dpcd_ext)) < 0)
> + return;
> +
> + if (intel_dp->dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV])
> + return;

I'm still missing the debug messages here and above... 

> +
> + if (memcmp(_dp->dpcd[DP_DPCD_REV], _ext[DP_DPCD_REV],
> +sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Revision 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DPCD_REV],
> +   dpcd_ext[DP_DPCD_REV]);
> + memcpy(_dp->dpcd[DP_DPCD_REV],
> +_ext[DP_DPCD_REV], sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_MAX_LINK_RATE],
> +   dpcd_ext[DP_MAX_LINK_RATE]);
> + memcpy(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port 
> Present  previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +   dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
> + memcpy(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT],
> +sizeof(u8));
> + }
> + }
> +}
> +
> +
>  bool
>  intel_dp_read_dpcd(struct intel_dp *intel_dp)
>  {
> @@ -3738,6 +3790,8 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>sizeof(intel_dp->dpcd)) < 0)
>   return false; /* aux transfer failed */
>  
> + intel_dp_extended_receiver_capabilities(intel_dp);
> +
>   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
> intel_dp->dpcd);
>  
>   return intel_dp->dpcd[DP_DPCD_REV] != 0;
> -- 
> 2.17.1
> 
___
Intel-gfx mailing list

[Intel-gfx] ✓ Fi.CI.BAT: success for Add Colorspace connector property interface

[Patchwork]

== Series Details ==

Series: Add Colorspace connector property interface
URL   : https://patchwork.freedesktop.org/series/47132/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4535 -> Patchwork_9757 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/47132/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_module_reload@basic-no-display:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106725)

igt@kms_chamelium@common-hpd-after-suspend:
  fi-skl-6700k2:  PASS -> INCOMPLETE (fdo#104108, k.org#199541, 
fdo#105524)

igt@kms_flip@basic-flip-vs-modeset:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106097, fdo#106000)

igt@kms_flip@basic-flip-vs-wf_vblank:
  fi-glk-j4005:   PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@drv_selftest@live_coherency:
  fi-byt-j1900:   DMESG-FAIL -> PASS

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-glk-j4005:   DMESG-WARN (fdo#106000) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
  fdo#105524 https://bugs.freedesktop.org/show_bug.cgi?id=105524
  fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725
  k.org#199541 https://bugzilla.kernel.org/show_bug.cgi?id=199541


== Participating hosts (52 -> 44) ==

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-skl-caroline fi-byt-clapper fi-bdw-samus 


== Build changes ==

* Linux: CI_DRM_4535 -> Patchwork_9757

  CI_DRM_4535: 79a6a05d5beb28987746b0ea61837783a4af4e82 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4573: 2884f91dd6d7682ea738ef6f0943cc591643dda2 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9757: bfaa2413cf37fbf7ef53ddaa67b122e20f4edd2e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bfaa2413cf37 drm/i915: Set colorspace by enabling Infoframe
d223f56b07d5 drm/i915: Attach colorspace property and enable modeset
6ef31f2983ca drm: Add colorspace property

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/dp: add extended receiver capability field present bit

[Rodrigo Vivi]

On Mon, Jul 23, 2018 at 02:27:34PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> This bit was added to DP Training Aux RD interval with DP 1.3. Via
> descriptiion of the spec this field indicates the panels true
> capabilities are described in DPCD address space 02200h through 022FFh.
> 
> v2: version comment update
> v3: version comment correction, commit message update
> v4: white space correction

I'm afraid the wrong space that I had mentioned it is still there
s/"(1 << 7)/* DP 1.3 */"/"(1 << 7) /* DP 1.3 *"/g

> 
> Signed-off-by: Matt Atwood 
> ---
>  include/drm/drm_dp_helper.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c01564991a9f..44aaefdc8448 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -123,8 +123,9 @@
>  # define DP_FRAMING_CHANGE_CAP   (1 << 1)
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
> -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
> +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* DP 1.3 */
> +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT  (1 << 7)/* DP 1.3 */
^ here

>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.17.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add Colorspace connector property interface

[Patchwork]

== Series Details ==

Series: Add Colorspace connector property interface
URL   : https://patchwork.freedesktop.org/series/47132/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm: Add colorspace property
Okay!

Commit: drm/i915: Attach colorspace property and enable modeset
Okay!

Commit: drm/i915: Set colorspace by enabling Infoframe
+drivers/gpu/drm/i915/intel_hdmi.c:494:52: int enum extended_colorimetry  
versus
+drivers/gpu/drm/i915/intel_hdmi.c:494:52: int enum 
hdmi_extended_colorimetry 
+drivers/gpu/drm/i915/intel_hdmi.c:494:52: warning: mixing different enum types

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface

[Patchwork]

== Series Details ==

Series: Add Colorspace connector property interface
URL   : https://patchwork.freedesktop.org/series/47132/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6ef31f2983ca drm: Add colorspace property
d223f56b07d5 drm/i915: Attach colorspace property and enable modeset
-:33: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#33: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2101:
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.colorspace_property,

total: 0 errors, 0 warnings, 1 checks, 16 lines checked
bfaa2413cf37 drm/i915: Set colorspace by enabling Infoframe

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

[Intel-gfx] [RFC 2/3] drm/i915: Attach colorspace property and enable modeset

[Uma Shankar]

This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_atomic.c | 1 +
 drivers/gpu/drm/i915/intel_hdmi.c   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index b04952b..8e7d540 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+   new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index d06cf42..7fb96e2 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2110,6 +2110,9 @@ static void intel_hdmi_destroy(struct drm_connector 
*connector)
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.colorspace_property,
+   EXTENDED_COLORIMETRY_XV_YCC_601);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 }
 
-- 
1.9.1

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

[Intel-gfx] [RFC 3/3] drm/i915: Set colorspace by enabling Infoframe

[Uma Shankar]

Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 7fb96e2..319da1b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -491,6 +491,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+   frame.avi.extended_colorimetry = conn_state->colorspace;
+
drm_hdmi_avi_infoframe_quant_range(, adjusted_mode,
   crtc_state->limited_color_range ?
   HDMI_QUANTIZATION_RANGE_LIMITED :
-- 
1.9.1

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

[Intel-gfx] [RFC 0/3] Add Colorspace connector property interface

[Uma Shankar]

This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scenarios, a
particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Kernel will not give the supported colorspaces since
this is panel dependant and our curremt property infrastructure is
not supporting it. 

Have tested this using xrandr by using below command:
xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"

Please provide comments on this current approach. This is just an RFC
to get some feedback. Will refine the series based on inputs and
feedback.

Uma Shankar (3):
  drm: Add colorspace property
  drm/i915: Attach colorspace property and enable modeset
  drm/i915: Set colorspace by enabling Infoframe

 drivers/gpu/drm/drm_atomic.c|  4 
 drivers/gpu/drm/drm_connector.c | 31 +++
 drivers/gpu/drm/i915/intel_atomic.c |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c   |  5 +
 include/drm/drm_connector.h |  7 +++
 include/drm/drm_mode_config.h   |  6 ++
 include/uapi/drm/drm_mode.h | 11 +++
 7 files changed, 65 insertions(+)

-- 
1.9.1

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

[Intel-gfx] [RFC 1/3] drm: Add colorspace property

[Uma Shankar]

This patch adds a colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic.c|  4 
 drivers/gpu/drm/drm_connector.c | 31 +++
 include/drm/drm_connector.h |  7 +++
 include/drm/drm_mode_config.h   |  6 ++
 include/uapi/drm/drm_mode.h | 11 +++
 5 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e..f065e6f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1397,6 +1397,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+   } else if (property == config->colorspace_property) {
+   state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1502,6 +1504,8 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == config->colorspace_property) {
+   *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5ada064..cfe1d79 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -805,6 +805,25 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 };
 DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
 
+static const struct drm_prop_enum_list colorspace[] = {
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { EXTENDED_COLORIMETRY_XV_YCC_601, "601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { EXTENDED_COLORIMETRY_XV_YCC_709, "709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { EXTENDED_COLORIMETRY_S_YCC_601, "s601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { EXTENDED_COLORIMETRY_ADOBE_YCC_601, "adobe601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { EXTENDED_COLORIMETRY_ADOBE_RGB, "adobe_rgb" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { EXTENDED_COLORIMETRY_BT2020_RGB, "BT2020_rgb" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { EXTENDED_COLORIMETRY_BT2020_YCC, "BT2020_ycc" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { EXTENDED_COLORIMETRY_BT2020_CYCC, "BT2020_cycc" },
+};
+
 /**
  * DOC: standard connector properties
  *
@@ -951,6 +970,12 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
  * can also expose this property to external outputs, in which case they
  * must support "None", which should be the default (since external screens
  * have a built-in scaler).
+ *
+ * colorspace:
+ * This property helps select a suitable colorspace based on the sink
+ * capability. Modern sink devices support wider gamut like BT2020.
+ * This helps switch to BT2020 mode if the BT2020 encoded video stream
+ * is being played by the user, same for any other colorspace.
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -999,6 +1024,12 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
 
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
+   colorspace, ARRAY_SIZE(colorspace));
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.colorspace_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index a5179eb..306b536 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -443,6 +443,13 @@ struct drm_connector_state {
unsigned int content_protection;
 
/**
+* @colorspace: Connector property to request colorspace
+* change. This is most commonly used to switch to wider color
+* gamuts like BT2020.
+*/
+   enum extended_colorimetry colorspace;
+
+   /**
 * @writeback_job: Writeback job for writeback connectors
 *
 * Holds the framebuffer and out-fence for a writeback connector. As
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Protect guc_fini_wq() against module load abort (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Protect guc_fini_wq() against module load abort (rev2)
URL   : https://patchwork.freedesktop.org/series/47127/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4534 -> Patchwork_9756 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/47127/revisions/2/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-skl-6700k2:  PASS -> DMESG-FAIL (fdo#106560, fdo#107174)
  fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)

igt@kms_chamelium@dp-crc-fast:
  fi-kbl-7500u:   PASS -> DMESG-FAIL (fdo#103841)


 Possible fixes 

igt@gem_exec_flush@basic-wb-ro-default:
  fi-glk-j4005:   DMESG-WARN (fdo#105719) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS


  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174


== Participating hosts (52 -> 44) ==

  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-skl-caroline fi-byt-clapper fi-bdw-samus 


== Build changes ==

* Linux: CI_DRM_4534 -> Patchwork_9756

  CI_DRM_4534: a59bbda34ede6f5685fdc86b58f143bada751617 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4572: 9b064015df14506b23cd2d7245a73e1b1d16ee1f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9756: cbd1dfaa9f3c1b9dff51c78195c666f41ba53f20 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

cbd1dfaa9f3c drm/i915: Protect guc_fini_wq() against module load abort

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9756/issues.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 mm, oom: distinguish blockable mode for mmu notifiers (rev8)

[Patchwork]

== Series Details ==

Series: mm, oom: distinguish blockable mode for mmu notifiers (rev8)
URL   : https://patchwork.freedesktop.org/series/45263/
State : failure

== Summary ==

Applying: mm, oom: distinguish blockable mode for mmu notifiers
error: sha1 information is lacking or useless (mm/oom_kill.c).
error: could not build fake ancestor
Patch failed at 0001 mm, oom: distinguish blockable mode for mmu notifiers
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] [PATCH v2] drm/i915: Protect guc_fini_wq() against module load abort

[Chris Wilson]

Prevent
[  397.873143] general protection fault:  [#1] PREEMPT SMP PTI
[  397.873154] CPU: 4 PID: 4799 Comm: drv_module_relo Tainted: G U  
  4.18.0-rc6-CI-CI_DRM_4534+ #1
[  397.873162] Hardware name: Micro-Star International Co., Ltd. MS-7B54/Z370M 
MORTAR (MS-7B54), BIOS 1.10 12/28/2017
[  397.873175] RIP: 0010:__lock_acquire+0xf6/0x1b50
[  397.873179] Code: 85 c0 4c 8b 9d 40 ff ff ff 8b 8d 38 ff ff ff 44 8b 8d 30 
ff ff ff 4c 8b 85 28 ff ff ff 44 8b 95 24 ff ff ff 0f 84 54 03 00 00  ff 80 
38 01 00 00 8b 15 45 8c 59 02 45 8b bc 24 70 08 00 00 85
[  397.873240] RSP: 0018:c9497b40 EFLAGS: 00010002
[  397.873246] RAX: 6b6b6b6b6b6b6b6b RBX: 0001 RCX: 
[  397.873252] RDX: 0046 RSI:  RDI: 
[  397.873258] RBP: c9497c20 R08: 810a25e9 R09: 
[  397.873264] R10:  R11: 880255c63c28 R12: 8801093b2840
[  397.873270] R13: 0001 R14: 0001 R15: 0246
[  397.873277] FS:  7faf88d71980() GS:88026630() 
knlGS:
[  397.873284] CS:  0010 DS:  ES:  CR0: 80050033
[  397.873289] CR2: 55d866c9ca10 CR3: 00025472e006 CR4: 003606e0
[  397.873295] DR0:  DR1:  DR2: 
[  397.873301] DR3:  DR6: fffe0ff0 DR7: 0400
[  397.873308] Call Trace:
[  397.873318]  ? lock_acquire+0xa6/0x210
[  397.873323]  lock_acquire+0xa6/0x210
[  397.873331]  ? drain_workqueue+0x19/0x180
[  397.873339]  __mutex_lock+0x89/0x980
[  397.873346]  ? drain_workqueue+0x19/0x180
[  397.873352]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
[  397.873359]  ? trace_hardirqs_on_caller+0xe0/0x1b0
[  397.873365]  ? drain_workqueue+0x19/0x180
[  397.873373]  ? debug_object_active_state+0x127/0x150
[  397.873381]  ? drain_workqueue+0x19/0x180
[  397.873387]  drain_workqueue+0x19/0x180
[  397.873395]  destroy_workqueue+0x12/0x1f0
[  397.873476]  intel_guc_fini_misc+0x36/0x90 [i915]
[  397.873540]  i915_gem_fini+0x91/0x100 [i915]
[  397.873588]  i915_driver_unload+0xd2/0x110 [i915]
[  397.873638]  i915_pci_remove+0x19/0x30 [i915]
[  397.873646]  pci_device_remove+0x36/0xb0
[  397.873653]  device_release_driver_internal+0x185/0x250
[  397.873660]  driver_detach+0x35/0x70
[  397.873668]  bus_remove_driver+0x53/0xd0
[  397.873675]  pci_unregister_driver+0x25/0xa0
[  397.873683]  __se_sys_delete_module+0x162/0x210
[  397.873691]  ? do_syscall_64+0xd/0x190
[  397.873697]  do_syscall_64+0x55/0x190
[  397.873704]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  397.873710] RIP: 0033:0x7faf884231b7
[  397.873714] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48
[  397.873775] RSP: 002b:7ffda4e98cf8 EFLAGS: 0206 ORIG_RAX: 
00b0
[  397.873784] RAX: ffda RBX:  RCX: 7faf884231b7
[  397.873790] RDX:  RSI: 0800 RDI: 55fbb18f1bd8
[  397.873796] RBP: 55fbb18f1b70 R08: 55fbb18f1bdc R09: 7ffda4e98d38
[  397.873802] R10: 7ffda4e97cf4 R11: 0206 R12: 55fbb0d32470
[  397.873808] R13: 7ffda4e992e0 R14:  R15: 

v2: It's use-after-free; not a NULL pointer.

Testcase: igt/drv_module_reload/basic-reload-inject
Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 846d693ecb53..3082d7670f05 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -128,13 +128,15 @@ static int guc_init_wq(struct intel_guc *guc)
 
 static void guc_fini_wq(struct intel_guc *guc)
 {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct workqueue_struct *wq;
 
-   if (HAS_LOGICAL_RING_PREEMPTION(dev_priv) &&
-   USES_GUC_SUBMISSION(dev_priv))
-   destroy_workqueue(guc->preempt_wq);
+   wq = fetch_and_zero(>preempt_wq);
+   if (wq)
+   destroy_workqueue(wq);
 
-   destroy_workqueue(guc->log.relay.flush_wq);
+   wq = fetch_and_zero(>log.relay.flush_wq);
+   if (wq)
+   destroy_workqueue(wq);
 }
 
 int intel_guc_init_misc(struct intel_guc *guc)
-- 
2.18.0

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

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Michal Hocko]

On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> - Undocumented return value.
> 
> - comment "failed to reap part..." is misleading - sounds like it's
>   referring to something which happened in the past, is in fact
>   referring to something which might happen in the future.
> 
> - fails to call trace_finish_task_reaping() in one case
> 
> - code duplication.
> 
> - Increases mmap_sem hold time a little by moving
>   trace_finish_task_reaping() inside the locked region.  So sue me ;)
> 
> - Sharing the finish: path means that the trace event won't
>   distinguish between the two sources of finishing.
> 
> Please take a look?

oom_reap_task_mm should return false when __oom_reap_task_mm return
false. This is what my patch did but it seems this changed by
http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
so that one should be fixed.

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 104ef4a01a55..88657e018714 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -565,7 +565,7 @@ static bool oom_reap_task_mm(struct task_struct *tsk, 
struct mm_struct *mm)
/* failed to reap part of the address space. Try again later */
if (!__oom_reap_task_mm(mm)) {
up_read(>mmap_sem);
-   return true;
+   return false;
}
 
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, 
file-rss:%lukB, shmem-rss:%lukB\n",


On top of that the proposed cleanup looks as follows:

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 88657e018714..4e185a282b3d 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -541,8 +541,16 @@ bool __oom_reap_task_mm(struct mm_struct *mm)
return ret;
 }
 
+/*
+ * Reaps the address space of the give task.
+ *
+ * Returns true on success and false if none or part of the address space
+ * has been reclaimed and the caller should retry later.
+ */
 static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
 {
+   bool ret = true;
+
if (!down_read_trylock(>mmap_sem)) {
trace_skip_task_reaping(tsk->pid);
return false;
@@ -555,28 +563,28 @@ static bool oom_reap_task_mm(struct task_struct *tsk, 
struct mm_struct *mm)
 * down_write();up_write() cycle in exit_mmap().
 */
if (test_bit(MMF_OOM_SKIP, >flags)) {
-   up_read(>mmap_sem);
trace_skip_task_reaping(tsk->pid);
-   return true;
+   goto out_unlock;
}
 
trace_start_task_reaping(tsk->pid);
 
/* failed to reap part of the address space. Try again later */
-   if (!__oom_reap_task_mm(mm)) {
-   up_read(>mmap_sem);
-   return false;
-   }
+   ret = __oom_reap_task_mm(mm);
+   if (!ret)
+   goto out_finish;
 
pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, 
file-rss:%lukB, shmem-rss:%lukB\n",
task_pid_nr(tsk), tsk->comm,
K(get_mm_counter(mm, MM_ANONPAGES)),
K(get_mm_counter(mm, MM_FILEPAGES)),
K(get_mm_counter(mm, MM_SHMEMPAGES)));
+out_finish:
+   trace_finish_task_reaping(tsk->pid);
+out_unlock:
up_read(>mmap_sem);
 
-   trace_finish_task_reaping(tsk->pid);
-   return true;
+   return ret;
 }
 
 #define MAX_OOM_REAP_RETRIES 10
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Protect guc_fini_wq() against module load abort

[Chris Wilson]

Quoting Chris Wilson (2018-07-24 14:40:46)
> Prevent
> [  397.873143] general protection fault:  [#1] PREEMPT SMP PTI
> [  397.873154] CPU: 4 PID: 4799 Comm: drv_module_relo Tainted: G U
> 4.18.0-rc6-CI-CI_DRM_4534+ #1
> [  397.873162] Hardware name: Micro-Star International Co., Ltd. 
> MS-7B54/Z370M MORTAR (MS-7B54), BIOS 1.10 12/28/2017
> [  397.873175] RIP: 0010:__lock_acquire+0xf6/0x1b50
> [  397.873179] Code: 85 c0 4c 8b 9d 40 ff ff ff 8b 8d 38 ff ff ff 44 8b 8d 30 
> ff ff ff 4c 8b 85 28 ff ff ff 44 8b 95 24 ff ff ff 0f 84 54 03 00 00  ff 
> 80 38 01 00 00 8b 15 45 8c 59 02 45 8b bc 24 70 08 00 00 85
> [  397.873240] RSP: 0018:c9497b40 EFLAGS: 00010002
> [  397.873246] RAX: 6b6b6b6b6b6b6b6b RBX: 0001 RCX: 
> 

On second thoughts, that's POISON_FREE.
-Chris
___
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: Protect guc_fini_wq() against module load abort

[Patchwork]

== Series Details ==

Series: drm/i915: Protect guc_fini_wq() against module load abort
URL   : https://patchwork.freedesktop.org/series/47127/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4534 -> Patchwork_9754 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/47127/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@mock_sanitycheck:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#107344)

igt@kms_flip@basic-flip-vs-dpms:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106000, fdo#106097)

igt@kms_flip@basic-plain-flip:
  fi-glk-j4005:   PASS -> DMESG-WARN (fdo#106097)


 Possible fixes 

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: DMESG-FAIL (fdo#107292) -> PASS

igt@gem_exec_flush@basic-wb-ro-default:
  fi-glk-j4005:   DMESG-WARN (fdo#105719) -> PASS


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

  fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
  fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
  fdo#107344 https://bugs.freedesktop.org/show_bug.cgi?id=107344


== Participating hosts (52 -> 43) ==

  Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-ctg-p8600 fi-icl-u fi-skl-caroline fi-byt-clapper fi-bdw-samus 


== Build changes ==

* Linux: CI_DRM_4534 -> Patchwork_9754

  CI_DRM_4534: a59bbda34ede6f5685fdc86b58f143bada751617 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4572: 9b064015df14506b23cd2d7245a73e1b1d16ee1f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9754: a210f55676b8ed911808f92836edc7e401e131f5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

a210f55676b8 drm/i915: Protect guc_fini_wq() against module load abort

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Protect guc_fini_wq() against module load abort

[Chris Wilson]

Prevent
[  397.873143] general protection fault:  [#1] PREEMPT SMP PTI
[  397.873154] CPU: 4 PID: 4799 Comm: drv_module_relo Tainted: G U  
  4.18.0-rc6-CI-CI_DRM_4534+ #1
[  397.873162] Hardware name: Micro-Star International Co., Ltd. MS-7B54/Z370M 
MORTAR (MS-7B54), BIOS 1.10 12/28/2017
[  397.873175] RIP: 0010:__lock_acquire+0xf6/0x1b50
[  397.873179] Code: 85 c0 4c 8b 9d 40 ff ff ff 8b 8d 38 ff ff ff 44 8b 8d 30 
ff ff ff 4c 8b 85 28 ff ff ff 44 8b 95 24 ff ff ff 0f 84 54 03 00 00  ff 80 
38 01 00 00 8b 15 45 8c 59 02 45 8b bc 24 70 08 00 00 85
[  397.873240] RSP: 0018:c9497b40 EFLAGS: 00010002
[  397.873246] RAX: 6b6b6b6b6b6b6b6b RBX: 0001 RCX: 
[  397.873252] RDX: 0046 RSI:  RDI: 
[  397.873258] RBP: c9497c20 R08: 810a25e9 R09: 
[  397.873264] R10:  R11: 880255c63c28 R12: 8801093b2840
[  397.873270] R13: 0001 R14: 0001 R15: 0246
[  397.873277] FS:  7faf88d71980() GS:88026630() 
knlGS:
[  397.873284] CS:  0010 DS:  ES:  CR0: 80050033
[  397.873289] CR2: 55d866c9ca10 CR3: 00025472e006 CR4: 003606e0
[  397.873295] DR0:  DR1:  DR2: 
[  397.873301] DR3:  DR6: fffe0ff0 DR7: 0400
[  397.873308] Call Trace:
[  397.873318]  ? lock_acquire+0xa6/0x210
[  397.873323]  lock_acquire+0xa6/0x210
[  397.873331]  ? drain_workqueue+0x19/0x180
[  397.873339]  __mutex_lock+0x89/0x980
[  397.873346]  ? drain_workqueue+0x19/0x180
[  397.873352]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
[  397.873359]  ? trace_hardirqs_on_caller+0xe0/0x1b0
[  397.873365]  ? drain_workqueue+0x19/0x180
[  397.873373]  ? debug_object_active_state+0x127/0x150
[  397.873381]  ? drain_workqueue+0x19/0x180
[  397.873387]  drain_workqueue+0x19/0x180
[  397.873395]  destroy_workqueue+0x12/0x1f0
[  397.873476]  intel_guc_fini_misc+0x36/0x90 [i915]
[  397.873540]  i915_gem_fini+0x91/0x100 [i915]
[  397.873588]  i915_driver_unload+0xd2/0x110 [i915]
[  397.873638]  i915_pci_remove+0x19/0x30 [i915]
[  397.873646]  pci_device_remove+0x36/0xb0
[  397.873653]  device_release_driver_internal+0x185/0x250
[  397.873660]  driver_detach+0x35/0x70
[  397.873668]  bus_remove_driver+0x53/0xd0
[  397.873675]  pci_unregister_driver+0x25/0xa0
[  397.873683]  __se_sys_delete_module+0x162/0x210
[  397.873691]  ? do_syscall_64+0xd/0x190
[  397.873697]  do_syscall_64+0x55/0x190
[  397.873704]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  397.873710] RIP: 0033:0x7faf884231b7
[  397.873714] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48
[  397.873775] RSP: 002b:7ffda4e98cf8 EFLAGS: 0206 ORIG_RAX: 
00b0
[  397.873784] RAX: ffda RBX:  RCX: 7faf884231b7
[  397.873790] RDX:  RSI: 0800 RDI: 55fbb18f1bd8
[  397.873796] RBP: 55fbb18f1b70 R08: 55fbb18f1bdc R09: 7ffda4e98d38
[  397.873802] R10: 7ffda4e97cf4 R11: 0206 R12: 55fbb0d32470
[  397.873808] R13: 7ffda4e992e0 R14:  R15: 

Testcase: igt/drv_module_reload/basic-reload-inject
Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 846d693ecb53..afb217d7ffdf 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -128,13 +128,11 @@ static int guc_init_wq(struct intel_guc *guc)
 
 static void guc_fini_wq(struct intel_guc *guc)
 {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
-   if (HAS_LOGICAL_RING_PREEMPTION(dev_priv) &&
-   USES_GUC_SUBMISSION(dev_priv))
+   if (guc->preempt_wq)
destroy_workqueue(guc->preempt_wq);
 
-   destroy_workqueue(guc->log.relay.flush_wq);
+   if (guc->log.relay.flush_wq)
+   destroy_workqueue(guc->log.relay.flush_wq);
 }
 
 int intel_guc_init_misc(struct intel_guc *guc)
-- 
2.18.0

___
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 v6 2/4] lib/igt_pm: Find HDA device when attempting to enable runtime PM

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-24 11:29:31)
> From: Tvrtko Ursulin 
> 
> HDA audio device can be present at various PCI paths on different systems
> which the existing code did not account for.
> 
> Furthermore the failure to enable runtime PM was silent leaving callers
> in the dark.
> 
> Improve it by auto-locating the PCI path and logging a warning when
> something is not as expected.
> 
> v2:
>  * If there is no audio hw/driver there is no failure.
> 
> v3:
>  * Comment.
>  * Skip non-symlinks.
>  * Free path on failure and restore.
>  * Simplify with asprintf. (Chris Wilson)
> 
> v4:
>  * Find snd_hda_intel instance tied with an Intel device.
> 
> v5:
>  * Fix memory leak and silence Valgrind warning.
> 
> v6:
>  * Fix error out logic.
> 
> Signed-off-by: Tvrtko Ursulin 

CI looks promising, as far my knowledge goes (and I am sorry to say
finding the child devices is beyond my sysfs ken), series is
Reviewed-by: Chris Wilson 
-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 3/4] igt/gem_exec_schedule: Trim deep runtime

[Chris Wilson]

Quoting Katarzyna Dec (2018-07-24 13:08:25)
> On Mon, Jul 23, 2018 at 09:07:35PM +0100, Chris Wilson wrote:
> > Time the runtime for emitting deep dependency tree, while keeping it
> > full of umpteen thousand requests.
> > 
> > Signed-off-by: Chris Wilson 
> 
> After conversation on IRC with dispelling doubts:
> Reviewed-by: Katarzyna Dec 

The test itself is just a nonsense stress test, trying to push the
system to the breaking point. Unfortunately the setup also demands that
it complete with 10s due to the use of an external fence, and CI runs
slowly (lockdep + allocation debugging is not fun). There are a myriad
possible dependency webs that are all interesting, so the only thing we
want to avoid are degenerate patterns that are resolved without looking
in the dfs (although analysing such degenerate patterns to make sure we
can take advantage of the degeneracy, because frankly most users fall
into simple patterns is also interesting, but not the purpose of this
investigation). As it is just a smoketest trying to exercise the dfs,
any such pattern is as good as any other. Again, this would be ideal to
script such that we could construct some arbitrary tree and evaluate the
execution order (going much further than the simple depth 1 trees we use
to prove the basics).

Hmm, really should investigate a few graph expression languages to see
if we can truly script this. Still have that 10s to worry about though.
-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 3/4] igt/gem_exec_schedule: Trim deep runtime

[Katarzyna Dec]

On Mon, Jul 23, 2018 at 09:07:35PM +0100, Chris Wilson wrote:
> Time the runtime for emitting deep dependency tree, while keeping it
> full of umpteen thousand requests.
> 
> Signed-off-by: Chris Wilson 

After conversation on IRC with dispelling doubts:
Reviewed-by: Katarzyna Dec 

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

Re: [Intel-gfx] [PATCH] drm/i915: Show stack (by WARN) for hitting forcewake errors

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-24 11:33:47)
> 
> On 20/07/2018 12:11, Chris Wilson wrote:
> > On Sandybridge, we need a workaround to wait for the CPU thread to wake
> > up before we are sure that we have enabled the GT power well. However,
> > we do see the errors being reported and failed reads returning spurious
> > results. To try and capture more details as it fails, promote the error
> > into a WARN so we grab the stacktrace, and to try and reduce the
> > frequency of error increase the timeout from 500us to 5ms.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   drivers/gpu/drm/i915/intel_uncore.c | 18 ++
> >   1 file changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index b892ca8396e8..284be151f645 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -283,14 +283,24 @@ fw_domains_reset(struct drm_i915_private *i915,
> >   fw_domain_reset(i915, d);
> >   }
> >   
> > +static inline u32 gt_thread_status(struct drm_i915_private *dev_priv)
> > +{
> > + u32 val;
> > +
> > + val = __raw_i915_read32(dev_priv, GEN6_GT_THREAD_STATUS_REG);
> > + val &= GEN6_GT_THREAD_STATUS_CORE_MASK;
> > +
> > + return val;
> > +}
> > +
> >   static void __gen6_gt_wait_for_thread_c0(struct drm_i915_private 
> > *dev_priv)
> >   {
> > - /* w/a for a sporadic read returning 0 by waiting for the GT
> > + /*
> > +  * w/a for a sporadic read returning 0 by waiting for the GT
> >* thread to wake up.
> >*/
> > - if (wait_for_atomic_us((__raw_i915_read32(dev_priv, 
> > GEN6_GT_THREAD_STATUS_REG) &
> > - GEN6_GT_THREAD_STATUS_CORE_MASK) == 0, 500))
> > - DRM_ERROR("GT thread status wait timed out\n");
> > + WARN_ONCE(wait_for_atomic_us(gt_thread_status(dev_priv) == 0, 5000),
> > +   "GT thread status wait timed out\n");
> >   }
> >   
> >   static void fw_domains_get_with_thread_status(struct drm_i915_private 
> > *dev_priv,
> > 
> 
> Quite a large increase - but I guess nothing we can do if it's hit, nor 
> it's better to time out faster if the wait needs to be longer.

It was a bit of a jump, but I felt that if we are prematurely declaring
the machine dead, we end up killing it anyway.

A long, long time ago, when we saw these errors it was terminal. The
recent sightings in CI however looked transient (hard to tell as we
panicked shortly after), so I'm betting on a longer timeout will help
the false positives (additional hardirq latency is better than death).
-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 1/4] lib: Don't assert all KMS drivers support edid_override

[Katarzyna Dec]

On Mon, Jul 23, 2018 at 09:07:33PM +0100, Chris Wilson wrote:
> edid_override is a i915.ko debugfs feature; just skip any kms test that
> depends on being able to override the edid.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107337
> Signed-off-by: Chris Wilson 

Reviewed-by: Katarzyna Dec 

> ---
>  lib/igt_kms.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 476a78623..c9e00c3bd 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -913,7 +913,7 @@ void kmstest_force_edid(int drm_fd, drmModeConnector 
> *connector,
>   debugfs_fd = igt_debugfs_open(drm_fd, path, O_WRONLY | O_TRUNC);
>   free(path);
>  
> - igt_assert(debugfs_fd != -1);
> + igt_require(debugfs_fd != -1);
>  
>   if (length == 0)
>   ret = write(debugfs_fd, "reset", 5);
> -- 
> 2.18.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] drm/i915: Show stack (by WARN) for hitting forcewake errors

[Tvrtko Ursulin]

On 20/07/2018 12:11, Chris Wilson wrote:

On Sandybridge, we need a workaround to wait for the CPU thread to wake
up before we are sure that we have enabled the GT power well. However,
we do see the errors being reported and failed reads returning spurious
results. To try and capture more details as it fails, promote the error
into a WARN so we grab the stacktrace, and to try and reduce the
frequency of error increase the timeout from 500us to 5ms.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_uncore.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index b892ca8396e8..284be151f645 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -283,14 +283,24 @@ fw_domains_reset(struct drm_i915_private *i915,
fw_domain_reset(i915, d);
  }
  
+static inline u32 gt_thread_status(struct drm_i915_private *dev_priv)

+{
+   u32 val;
+
+   val = __raw_i915_read32(dev_priv, GEN6_GT_THREAD_STATUS_REG);
+   val &= GEN6_GT_THREAD_STATUS_CORE_MASK;
+
+   return val;
+}
+
  static void __gen6_gt_wait_for_thread_c0(struct drm_i915_private *dev_priv)
  {
-   /* w/a for a sporadic read returning 0 by waiting for the GT
+   /*
+* w/a for a sporadic read returning 0 by waiting for the GT
 * thread to wake up.
 */
-   if (wait_for_atomic_us((__raw_i915_read32(dev_priv, 
GEN6_GT_THREAD_STATUS_REG) &
-   GEN6_GT_THREAD_STATUS_CORE_MASK) == 0, 500))
-   DRM_ERROR("GT thread status wait timed out\n");
+   WARN_ONCE(wait_for_atomic_us(gt_thread_status(dev_priv) == 0, 5000),
+ "GT thread status wait timed out\n");
  }
  
  static void fw_domains_get_with_thread_status(struct drm_i915_private *dev_priv,




Quite a large increase - but I guess nothing we can do if it's hit, nor 
it's better to time out faster if the wait needs to be longer.


Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH i-g-t v6 2/4] lib/igt_pm: Find HDA device when attempting to enable runtime PM

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

HDA audio device can be present at various PCI paths on different systems
which the existing code did not account for.

Furthermore the failure to enable runtime PM was silent leaving callers
in the dark.

Improve it by auto-locating the PCI path and logging a warning when
something is not as expected.

v2:
 * If there is no audio hw/driver there is no failure.

v3:
 * Comment.
 * Skip non-symlinks.
 * Free path on failure and restore.
 * Simplify with asprintf. (Chris Wilson)

v4:
 * Find snd_hda_intel instance tied with an Intel device.

v5:
 * Fix memory leak and silence Valgrind warning.

v6:
 * Fix error out logic.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_pm.c | 93 
 1 file changed, 79 insertions(+), 14 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 6f3b0a2d897d..94d4dd2d3c37 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drmtest.h"
 #include "igt_pm.h"
@@ -64,6 +65,7 @@ enum {
 #define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
 
 static char __igt_pm_audio_runtime_power_save[64];
+static char * __igt_pm_audio_runtime_control_path;
 static char __igt_pm_audio_runtime_control[64];
 
 static int __igt_pm_audio_restore_runtime_pm(void)
@@ -86,7 +88,7 @@ static int __igt_pm_audio_restore_runtime_pm(void)
 
close(fd);
 
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   fd = open(__igt_pm_audio_runtime_control_path, O_WRONLY);
if (fd < 0)
return errno;
 
@@ -100,6 +102,8 @@ static int __igt_pm_audio_restore_runtime_pm(void)
close(fd);
 
__igt_pm_audio_runtime_power_save[0] = 0;
+   free(__igt_pm_audio_runtime_control_path);
+   __igt_pm_audio_runtime_control_path = NULL;
 
return 0;
 }
@@ -130,36 +134,97 @@ static void strchomp(char *str)
  */
 void igt_pm_enable_audio_runtime_pm(void)
 {
+   char *path = NULL;
+   struct dirent *de;
+   DIR *dir;
int fd;
 
/* Check if already enabled. */
if (__igt_pm_audio_runtime_power_save[0])
return;
 
-   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
-   if (fd >= 0) {
-   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
-   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
-   strchomp(__igt_pm_audio_runtime_power_save);
-   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
-   igt_assert_eq(write(fd, "1\n", 2), 2);
+   dir = opendir("/sys/class/sound");
+   if (!dir)
+   return;
+
+   /* Find PCI device claimed by snd_hda_intel and tied to i915. */
+   while ((de = readdir(dir))) {
+   const char *match = "hwC";
+   char buf[32] = { }; /* for Valgrind */
+   char *tmp;
+   int ret;
+
+   if (de->d_type != DT_LNK ||
+   strncmp(de->d_name, match, strlen(match)))
+   continue;
+
+   igt_assert(asprintf(,
+   "/sys/class/sound/%s/vendor_name",
+   de->d_name));
+
+   fd = open(tmp, O_RDONLY);
+   free(tmp);
+   igt_assert_fd(fd);
+   ret = read(fd, buf, sizeof(buf));
close(fd);
+   igt_assert(ret > 0);
+   strchomp(buf);
+
+   /* Realtek and similar devices are not what we are after. */
+   if (strcmp(buf, "Intel"))
+   continue;
+
+   igt_assert(asprintf(,
+   
"/sys/class/sound/%s/device/device/power/control",
+   de->d_name));
+
+   igt_debug("Audio device path is %s\n", path);
+
+   break;
}
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
-   if (fd >= 0) {
-   igt_assert(read(fd, __igt_pm_audio_runtime_control,
-   sizeof(__igt_pm_audio_runtime_control)) > 0);
-   strchomp(__igt_pm_audio_runtime_control);
-   igt_assert_eq(write(fd, "auto\n", 5), 5);
+
+   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
+   if (fd < 0)
+   return;
+
+   /* snd_hda_intel loaded but no path found is an error. */
+   if (!path) {
close(fd);
+   errno = ESRCH;
+   goto err;
}
 
+   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+   strchomp(__igt_pm_audio_runtime_power_save);
+   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
+   igt_assert_eq(write(fd, "1\n", 2), 2);
+   close(fd);
+
+   fd = 

[Intel-gfx] [PATCH i-g-t v5 2/4] lib/igt_pm: Find HDA device when attempting to enable runtime PM

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

HDA audio device can be present at various PCI paths on different systems
which the existing code did not account for.

Furthermore the failure to enable runtime PM was silent leaving callers
in the dark.

Improve it by auto-locating the PCI path and logging a warning when
something is not as expected.

v2:
 * If there is no audio hw/driver there is no failure.

v3:
 * Comment.
 * Skip non-symlinks.
 * Free path on failure and restore.
 * Simplify with asprintf. (Chris Wilson)

v4:
 * Find snd_hda_intel instance tied with an Intel device.

v5:
 * Fix memory leak and silence Valgrind warning.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_pm.c | 93 +++-
 1 file changed, 77 insertions(+), 16 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 6f3b0a2d897d..21eb01e1903e 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drmtest.h"
 #include "igt_pm.h"
@@ -64,6 +65,7 @@ enum {
 #define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
 
 static char __igt_pm_audio_runtime_power_save[64];
+static char * __igt_pm_audio_runtime_control_path;
 static char __igt_pm_audio_runtime_control[64];
 
 static int __igt_pm_audio_restore_runtime_pm(void)
@@ -86,7 +88,7 @@ static int __igt_pm_audio_restore_runtime_pm(void)
 
close(fd);
 
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   fd = open(__igt_pm_audio_runtime_control_path, O_WRONLY);
if (fd < 0)
return errno;
 
@@ -100,6 +102,8 @@ static int __igt_pm_audio_restore_runtime_pm(void)
close(fd);
 
__igt_pm_audio_runtime_power_save[0] = 0;
+   free(__igt_pm_audio_runtime_control_path);
+   __igt_pm_audio_runtime_control_path = NULL;
 
return 0;
 }
@@ -130,36 +134,93 @@ static void strchomp(char *str)
  */
 void igt_pm_enable_audio_runtime_pm(void)
 {
+   char *path = NULL;
+   struct dirent *de;
+   DIR *dir;
int fd;
 
/* Check if already enabled. */
if (__igt_pm_audio_runtime_power_save[0])
return;
 
-   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
-   if (fd >= 0) {
-   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
-   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
-   strchomp(__igt_pm_audio_runtime_power_save);
-   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
-   igt_assert_eq(write(fd, "1\n", 2), 2);
-   close(fd);
-   }
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
-   if (fd >= 0) {
-   igt_assert(read(fd, __igt_pm_audio_runtime_control,
-   sizeof(__igt_pm_audio_runtime_control)) > 0);
-   strchomp(__igt_pm_audio_runtime_control);
-   igt_assert_eq(write(fd, "auto\n", 5), 5);
+   dir = opendir("/sys/class/sound");
+   if (!dir)
+   return;
+
+   /* Find PCI device claimed by snd_hda_intel and tied to i915. */
+   while ((de = readdir(dir))) {
+   const char *match = "hwC";
+   char buf[32] = { }; /* for Valgrind */
+   char *tmp;
+   int ret;
+
+   if (de->d_type != DT_LNK ||
+   strncmp(de->d_name, match, strlen(match)))
+   continue;
+
+   igt_assert(asprintf(,
+   "/sys/class/sound/%s/vendor_name",
+   de->d_name));
+
+   fd = open(tmp, O_RDONLY);
+   free(tmp);
+   igt_assert_fd(fd);
+   ret = read(fd, buf, sizeof(buf));
close(fd);
+   igt_assert(ret > 0);
+   strchomp(buf);
+
+   /* Realtek and similar devices are not what we are after. */
+   if (strcmp(buf, "Intel"))
+   continue;
+
+   igt_assert(asprintf(,
+   
"/sys/class/sound/%s/device/device/power/control",
+   de->d_name));
+
+   igt_debug("Audio device path is %s\n", path);
+
+   break;
}
 
+   if (!path)
+   goto err;
+
+   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
+   if (fd < 0)
+   goto err;
+
+   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+   strchomp(__igt_pm_audio_runtime_power_save);
+   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
+   igt_assert_eq(write(fd, "1\n", 2), 2);
+   close(fd);
+
+   fd = open(path, O_RDWR);
+   if (fd < 0)
+   goto err;
+
+   igt_assert(read(fd, __igt_pm_audio_runtime_control,

[Intel-gfx] [PATCH i-g-t v4 2/4] lib/igt_pm: Find HDA device when attempting to enable runtime PM

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

HDA audio device can be present at various PCI paths on different systems
which the existing code did not account for.

Furthermore the failure to enable runtime PM was silent leaving callers
in the dark.

Improve it by auto-locating the PCI path and logging a warning when
something is not as expected.

v2:
 * If there is no audio hw/driver there is no failure.

v3:
 * Comment.
 * Skip non-symlinks.
 * Free path on failure and restore.
 * Simplify with asprintf. (Chris Wilson)

v4:
 * Find snd_hda_intel instance tied with an Intel device.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_pm.c | 92 +++-
 1 file changed, 76 insertions(+), 16 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 6f3b0a2d897d..22d8d420c5d7 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drmtest.h"
 #include "igt_pm.h"
@@ -64,6 +65,7 @@ enum {
 #define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
 
 static char __igt_pm_audio_runtime_power_save[64];
+static char * __igt_pm_audio_runtime_control_path;
 static char __igt_pm_audio_runtime_control[64];
 
 static int __igt_pm_audio_restore_runtime_pm(void)
@@ -86,7 +88,7 @@ static int __igt_pm_audio_restore_runtime_pm(void)
 
close(fd);
 
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   fd = open(__igt_pm_audio_runtime_control_path, O_WRONLY);
if (fd < 0)
return errno;
 
@@ -100,6 +102,8 @@ static int __igt_pm_audio_restore_runtime_pm(void)
close(fd);
 
__igt_pm_audio_runtime_power_save[0] = 0;
+   free(__igt_pm_audio_runtime_control_path);
+   __igt_pm_audio_runtime_control_path = NULL;
 
return 0;
 }
@@ -130,36 +134,92 @@ static void strchomp(char *str)
  */
 void igt_pm_enable_audio_runtime_pm(void)
 {
+   char *path = NULL;
+   struct dirent *de;
+   DIR *dir;
int fd;
 
/* Check if already enabled. */
if (__igt_pm_audio_runtime_power_save[0])
return;
 
-   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
-   if (fd >= 0) {
-   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
-   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
-   strchomp(__igt_pm_audio_runtime_power_save);
-   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
-   igt_assert_eq(write(fd, "1\n", 2), 2);
-   close(fd);
-   }
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
-   if (fd >= 0) {
-   igt_assert(read(fd, __igt_pm_audio_runtime_control,
-   sizeof(__igt_pm_audio_runtime_control)) > 0);
-   strchomp(__igt_pm_audio_runtime_control);
-   igt_assert_eq(write(fd, "auto\n", 5), 5);
+   dir = opendir("/sys/class/sound");
+   if (!dir)
+   return;
+
+   /* Find PCI device claimed by snd_hda_intel and tied to i915. */
+   while ((de = readdir(dir))) {
+   const char *match = "hwC";
+   char buf[32];
+   char *tmp;
+   int ret;
+
+   if (de->d_type != DT_LNK ||
+   strncmp(de->d_name, match, strlen(match)))
+   continue;
+
+   igt_assert(asprintf(,
+   "/sys/class/sound/%s/vendor_name",
+   de->d_name));
+
+   fd = open(tmp, O_RDONLY);
+   igt_assert_fd(fd);
+   ret = read(fd, buf, sizeof(buf));
close(fd);
+   igt_assert(ret >= 0);
+   strchomp(buf);
+
+   /* Realtek and similar devices are not what we are after. */
+   if (strcmp(buf, "Intel"))
+   continue;
+
+   igt_assert(asprintf(,
+   
"/sys/class/sound/%s/device/device/power/control",
+   de->d_name));
+
+   igt_debug("Audio device path is %s\n", path);
+
+   break;
}
 
+   if (!path)
+   goto err;
+
+   fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_RDWR);
+   if (fd < 0)
+   goto err;
+
+   igt_assert(read(fd, __igt_pm_audio_runtime_power_save,
+   sizeof(__igt_pm_audio_runtime_power_save)) > 0);
+   strchomp(__igt_pm_audio_runtime_power_save);
+   igt_install_exit_handler(__igt_pm_audio_runtime_exit_handler);
+   igt_assert_eq(write(fd, "1\n", 2), 2);
+   close(fd);
+
+   fd = open(path, O_RDWR);
+   if (fd < 0)
+   goto err;
+
+   igt_assert(read(fd, __igt_pm_audio_runtime_control,
+   sizeof(__igt_pm_audio_runtime_control)) > 0);
+   

Re: [Intel-gfx] [PATCH] drm/i915: Pull unpin map into vma release

[Chris Wilson]

Quoting Michał Winiarski (2018-07-24 09:48:59)
> On Sat, Jul 21, 2018 at 01:50:37PM +0100, Chris Wilson wrote:
> > A reasonably common operation is to pin the map of the vma alongside the
> > vma itself for the lifetime of the vma, and so release both pin at the
> > same time as destroying the vma. It is common enough to pull into the
> > release function, making that central function more attractive to a
> > couple of other callsites.
> > 
> > The continual ulterior motive is to sweep over errors on module load
> > aborting...
> > 
> > Testcase: igt/drv_module_reload/basic-reload-inject
> > Signed-off-by: Chris Wilson 
> > Cc: Michał Winiarski 
> > Cc: Michal Wajdeczko 
> 
> Reviewed-by: Michał Winiarski 

Hopefully this was the last oops for drv_module_reload...
Now just need a random patch for igt, take your pick of
https://patchwork.freedesktop.org/series/47084/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Pull unpin map into vma release

[Michał Winiarski]

On Sat, Jul 21, 2018 at 01:50:37PM +0100, Chris Wilson wrote:
> A reasonably common operation is to pin the map of the vma alongside the
> vma itself for the lifetime of the vma, and so release both pin at the
> same time as destroying the vma. It is common enough to pull into the
> release function, making that central function more attractive to a
> couple of other callsites.
> 
> The continual ulterior motive is to sweep over errors on module load
> aborting...
> 
> Testcase: igt/drv_module_reload/basic-reload-inject
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 
> Cc: Michal Wajdeczko 

Reviewed-by: Michał Winiarski 

-Michał

> ---
>  drivers/gpu/drm/i915/i915_perf.c| 10 --
>  drivers/gpu/drm/i915/i915_vma.c |  5 -
>  drivers/gpu/drm/i915/i915_vma.h |  3 ++-
>  drivers/gpu/drm/i915/intel_engine_cs.c  | 18 +++---
>  drivers/gpu/drm/i915/intel_guc.c|  5 ++---
>  drivers/gpu/drm/i915/intel_guc_ads.c|  2 +-
>  drivers/gpu/drm/i915/intel_guc_ct.c |  7 ++-
>  drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
>  drivers/gpu/drm/i915/intel_guc_submission.c | 10 --
>  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
>  10 files changed, 24 insertions(+), 40 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx